How to automate stablecoins or crypto payouts with a crypto payout API

Paying one contractor in crypto is a manual task that takes two minutes. Paying four hundred of them every second Friday is an engineering problem. Somewhere between those two volumes, most finance teams stop copying addresses into a dashboard and ask a developer (or coding agent) to wire the payouts into the system that already knows who is owed what.

A crypto payout API is the component that does that work. This guide covers the six endpoints EukaPay exposes for payouts, the order you should call them in, and the one header that stops a retry from paying somebody twice.

A payout API moves value in the opposite direction from a payment gateway. Instead of collecting funds from a customer, you are sending funds to a recipient: a contractor, an affiliate, a player withdrawing a balance, or a vendor invoice you have approved for payment.

EukaPay exposes six endpoints for this work, all under

:

One point to be clear about, because it shapes how you design the integration:

creates

one

payout per call. There is no bulk endpoint that accepts an array of recipients. Paying four hundred contractors means four hundred calls, which is a solved problem once your queue and your idempotency keys are correct. If you would rather not build that loop, EukaPay also accepts a CSV upload in the merchant dashboard for batch runs. The API route and the CSV route reach the same payout rails.

Generate keys in the merchant dashboard under Settings > Integrations > API keys. Keys carry an environment prefix, so

keys work against staging and

keys work against production. The secret is displayed once at creation, so store it in your secret manager at that moment.

Authentication is a single custom header. There is no bearer token and no request signing on outbound calls:

Two details that catch developers out. The production host is

and staging is

. And there is no version prefix in the path: the endpoint is

, not

, even though the reference is labelled v1.0.

Every payout run should start by asking what is actually available.

answers that, and calling it first turns a mid-batch failure into a pre-batch decision.

The response is keyed by fiat currency, and it distinguishes your total from what you can actually spend:

Read

, not

. The two differ when funds are committed but not yet cleared, and a batch sized against

will fail partway through. If the available balance will not cover the run, top up from your settlement balance using

before you begin, rather than discovering the shortfall on payout two hundred and seventeen.

Network fees on a payout are real money and they vary by chain. The estimate endpoint prices a payout before you commit to it, which matters when the fee on one network is a rounding error and on another it is a meaningful percentage of a small payment.

The estimate endpoint is narrower than EukaPay's full currency list, and the constraint is worth designing around rather than discovering in production. It accepts

values of

,

,

and

only, and

values of

,

and

only.

Note also that estimate is the one create-shaped endpoint that does not accept

. It does not move money, so a repeated call costs you nothing beyond a request.

In practice this means USDT payouts on Tron are the cheapest high-volume option available, which is why most contractor and affiliate programmes settle on USDT over Tron once volume grows.

A payout is a single

call. One detail catches almost everyone: this endpoint takes

, not JSON. It is the only create endpoint in the API that does, because recipients in high-risk countries require a supporting document as a file part.

The response comes back as JSON:

Four field rules worth knowing before you write the loop.

and

are the only two formally required fields. You specify either

, which is the fiat amount to send, or

, which is the crypto amount, and never both. Minimum destination amounts are 0.001 BTC, 0.02 ETH, 100 USDT and 100 USDC. And

and

are required unless you pass a

for a saved recipient, which is the cleaner pattern for anyone you pay repeatedly.

accepts

,

,

,

or

, and

becomes required when you choose

. Recipients in grey-list countries require

, and recipients in Russia or Ukraine require both a

value and a

file part of up to 5 MB as PDF, JPG or PNG.

This is the section most payout tutorials skip, and it is the one that costs real money when it is missing.

A payout request can time out after the server has already accepted it. Your HTTP client sees a failure, your retry logic fires, and without protection the recipient is paid twice. Crypto payouts are irreversible, so there is no chargeback to fall back on.

EukaPay accepts an

header to close that gap. You generate the value, the documentation recommends a V4 UUID, it can be up to 255 characters, and keys expire after 24 hours. If a request arrives carrying a key EukaPay has already seen, it is recognised as a repeat rather than executed as a new payout.

Three rules make idempotency actually work:

If the API returns an

, treat it as a signal to stop and reconcile against

rather than to retry harder with a fresh key. EukaPay documents the three error types,

,

and

, alongside a 409 Conflict status for requests that conflict with another request.

A created payout is not a completed payout. EukaPay publishes six status values for a crypto payout:

deserves a note, because it does not appear in the status list of unlicensed payout providers. EukaPay is registered with FINTRAC in Canada and FinCEN in the United States, and a registered processor screens outbound transfers. Build for it: a payout sitting in

is working as designed, not stuck, and your internal status display should say so rather than showing your finance team a failure.

Polling

in a loop works, and it wastes your rate limit. Webhooks are the better pattern.

Configure an endpoint under Settings > Integrations > Webhooks. Four of EukaPay's eight webhook events cover payouts:

Every webhook arrives with an

header containing an HMAC of the payload, keyed to the secret for that webhook. The algorithm is

SHA-512

, not the SHA-256 most gateways use. If a reviewer or a linter suggests correcting it to SHA-256, the correction is wrong.

Use

rather than

. A plain string comparison returns as soon as it finds a differing character, which leaks information about how much of a forged signature was correct.

One detail to settle against your own account before you rely on it. EukaPay's documentation gives two instructions that do not agree: the written steps say to use the payload "as it is without any alteration or converting to json," while the accompanying code sample calls

on an already-parsed body. Those two inputs produce different bytes whenever key order or whitespace differs, so they cannot both be correct. Capture the raw body as your framework delivers it, verify one real webhook against it, and if verification fails, try the re-serialised form before assuming your HMAC code is wrong.

EukaPay retries a failed webhook delivery every 20 minutes for up to two hours. That schedule has a direct consequence: your handler will receive the same event more than once, and it must be safe to process twice. Record the

you have already handled and return early on a repeat.

Verify the signature, record the event, return a 2xx quickly, and do the slow work asynchronously. A handler that runs a database migration before responding will time out and trigger the retry schedule you were trying to avoid.

With the pieces above, a payout run at volume is a queue rather than a bulk API call:

The pattern scales because each payout is independent. A single failure retries on its own key without touching the other three hundred and ninety-nine.

Payouts and pay-ins run on the same EukaPay account and the same infrastructure: instant crypto-to-fiat conversion at a locked exchange rate to remove all crypto volatility, protection against chargebacks, support for a wide range of cryptocurrencies, and settlement in USD, EUR, GBP, CAD to your bank account. EukaPay supports most major cryptocurrencies like BTC, ETH, LTC, SOL, USDC, USDT.

Crypto pay-ins and crypto payouts are peers rather than separate products. The balance a customer payment settles into is the balance a contractor payout draws from, which means one integration and one reconciliation surface instead of two.

Create an account at

app.eukapay.com/signup

, complete verification, provide your legal business information, then generate an API key.

The full payout reference, including request and response schemas for all six endpoints, is at

docs.eukapay.com

. Generate a

key and run the flow against staging before you touch production. If you want the product context first, the

crypto payouts product page

covers what settles where.

Does EukaPay have a bulk crypto payout endpoint?

No.

creates one payout per call. For batch runs without writing a loop, EukaPay accepts a CSV upload in the merchant dashboard, which uses the same payout rails as the API.

How do I stop a retry from paying a recipient twice?

Send an

header with every payout request, derived from something stable like the payroll run plus the recipient identifier. Keys expire after 24 hours, so reconcile anything older against

.

What does the Reviewing payout status mean?

The payout is under compliance review before release. EukaPay is registered with FINTRAC and FinCEN, and a registered processor screens outbound transfers. A payout in

is progressing normally.

Which currencies and networks can I estimate payouts for?

accepts

,

,

and

, on

,

and

.

What hashing algorithm does EukaPay use for webhook signatures?

HMAC SHA-512, sent in the

header. Compute your comparison HMAC over the raw request body.

How often does EukaPay retry a failed webhook?

Every 20 minutes for up to two hours. Your handler should be idempotent, because it will receive repeats.

Can I pay out in fiat instead of crypto?

Yes. EukaPay settles to your bank account in USD, EUR, GBP, CAD, and Canadian merchants can also take Interac withdrawals.