A bulk payment API is the programmatic route for paying many recipients from your own system, instead of building a file and uploading it by hand. The term covers two different designs. In one, a single request carries a list of recipients and the provider processes that list. In the other, each request creates one payment, and your own code sends them one at a time. Both get called bulk, so the name alone does not tell you which one you are buying.

EukaPay's Payout API is the second design. It creates one payout per request, so a run covering many recipients is a loop your own code drives rather than a single call carrying a list. Paying many recipients without writing code stays on the CSV upload in the merchant dashboard. This guide covers what the term means, what each design leaves your system to build, and how to tell which route a given run belongs on.

The label describes an outcome, not a mechanic. Both designs end with many recipients paid from one system. What changes is where the sequence lives.

Some providers accept an array of recipients in a single call and process the entries on their side. Your code sends one request and then asks about the result. The appeal is fewer calls. The cost is that the sequence runs somewhere you cannot watch, so you often depend on a status lookup or a callback to learn what happened to any one line.

In the other design, a request creates a single payment. A run of many recipients is a sequence your own code controls, one call at a time. The payment run stops being an event that happens elsewhere and becomes a job inside your platform, with your own logging around it.

EukaPay uses this design. Each request to the Payout API creates one payout, with its asset and its network set per payout. Recipients in the same run can be paid in different assets on different networks, because nothing forces a run to be uniform. There is no batch endpoint. The

payout API

reference covers what a single request sends and what comes back.

The per-request design moves three jobs into your platform that a list-carrying request keeps on the provider's side. None is hard. All three are easier to build at the start than to retrofit after a run has gone out wrong.

A request that creates one payout creates a new payout every time it succeeds. A retry after a timeout can therefore pay the same recipient again, because your code cannot tell a lost response from a failed call. Keep your own record of which recipients already have a payout reference for this cycle. Check that record before sending, not after.

A run that keeps only a run-level status can be hard to resume safely, because nothing in your system can say which lines already went. Write the outcome per recipient as the loop runs. That record is also what your support team reads when one publisher asks about one payment, which is the question they actually get.

The payout balance is funded by transferring from your account's main balance. That transfer is a step in the run, not something that happens on its own. Build it in as a check so a cycle that collected late does not start a loop against a balance that cannot cover it.

Often not, and the honest answer changes what you build. If the run is periodic, if a person decides when it goes, and if the amounts are already settled in your own reporting, an upload does the same work with no integration. EukaPay covers that route with a CSV upload in the merchant dashboard, where the list is validated and shown with its recipients and amounts before anything is sent.

The API earns its place when the trigger is an event your own system already knows about. A cycle closing, a threshold crossed, or a balance going positive can start a run without anyone opening a dashboard. That is the real gain, and it is about who starts the run rather than how many calls it takes.

Moving a payout run into code

covers what shifts into your platform when you make that change, and

mass payment solutions

covers the wider vendor category if you are still shortlisting.

EukaPay supports both routes on the same account, so the decision is not permanent and does not have to cover the whole business. Put the recurring cycle your platform already tracks on the API, and leave the off-cycle run nobody wants to write code for on the upload. Read the endpoint reference before you build the loop, then move one cycle onto it.

The same EukaPay account that sends payouts also takes payments in, with instant crypto-to-fiat conversion at a locked exchange rate to remove your exposure to crypto price swings, support for most major cryptocurrencies, and settlement in USD, EUR, GBP, and CAD to your bank account. The locked rate is applied by default on every conversion, on pay-ins and on payouts. A crypto payment confirms on-chain, so protection against chargebacks is a property of the payment method.

For a platform that collects from one side and pays many recipients on the other, that means one integration and one set of records instead of two. If you are shopping for a bulk payment API, the first question to settle is which of the two designs sits behind it, because that answer sets the scope of your own build. EukaPay creates one payout per request and covers the no-code run with the dashboard upload, so start with the route that matches the run in front of you.

Create an account at

app.eukapay.com/signup

, complete verification, provide your legal business information, and generate an API key. The payout endpoints, the balance transfer, invoices, subscriptions, and customers are documented at

docs.eukapay.com

, and a staging environment is available for development while you build.

What is a bulk payment API?

A bulk payment API is an interface your own system calls to pay many recipients, instead of a person doing it in a dashboard. The term covers two designs: one request carrying a list of recipients, or one request creating one payment.

Does EukaPay's payout API send to many recipients in one request?

No. EukaPay's Payout API creates one payout per request, so a run covering many recipients is a loop your code drives. There is no batch endpoint.

Can I pay many recipients without writing code?

Yes. Upload a recipient list as a CSV file in the merchant dashboard. The list is validated and shown with its recipients and amounts before anything is sent.

Which cryptocurrencies can EukaPay send in a payout?

Payouts are sent in USDC, USDT, ETH, and BTC, on the Ethereum, Tron, and Bitcoin networks. The asset and the network are set per payout.

How do I stop a retried request from paying a recipient twice?

Each successful request creates a new payout, so a retry can send a second payment. Keep your own record of which recipients already have a payout reference for the cycle, and check it before you send again.

How is the payout balance funded before a run?

The payout balance is funded by transferring from your account's main balance. Treat that transfer as a step in the run.

Do crypto payouts depend on banking hours?

Crypto payouts are not tied to banking hours or the banking calendar. Fiat settlement to your own bank account is a separate leg with its own timing.