Crypto payments API: the endpoints and what each one is for

"Crypto payments API" gets used two ways. Sometimes it means one endpoint that returns a hosted checkout link, and the payer does the rest in a browser. Sometimes it means a resource-oriented surface you build a real workflow against: create a customer, bill them once or on a schedule, pay someone out, move your own balance around, and get told when each of those things happens. An engineer, or a coding agent working from their spec, needs to know which one they are looking at before writing a line of code.

This guide walks the documented EukaPay API resources one at a time: what each one is for, the request fields that matter, and where your own system still owns the work after the call succeeds. It does not cover setup steps or account creation. That lives at docs.eukapay.com.

EukaPay's documented API surface is five resources: invoices, subscriptions, customers, payouts, and balance transfer. Some teams call this a cryptocurrency payment API instead of a crypto payments API. Both names describe the same surface at docs.eukapay.com.

POST /invoices creates a payment request. The required fields are price and currencyId. Optional fields include receiveCurrencyType (fiat or crypto, defaulting to fiat), a customerCode to attach the invoice to an existing customer, and a redirectUri for after payment. A minimal creation body looks like this:

GET /invoices lists existing invoices and returns each one's status: Draft, Unpaid, Cancelled, Overdue, Paid, Underpaid, or Overpaid. The invoice is where the hosted payment page comes from. The payer still completes the payment in their own browser; the API only creates and tracks the request.

POST /subscriptions creates a recurring billing arrangement on an interval from daily to annually. It sends a new invoice each period. There is no plan management and no programmatic retry logic layered on top; it is a scheduled invoice generator, not a full billing engine.

POST /customers creates a customer record, typed as invoicing, cryptoPayout, or both. An invoicing customer needs an email; a cryptoPayout customer can carry a saved wallet address so a payout can reference customerCode instead of repeating recipient details on every call.

GET /payouts returns an array of existing payout objects already sent to a bank account. POST /crypto_payouts is the one that sends cryptocurrency out. It creates one crypto payout per request, addressed to a cryptocurrencySymbol of USDC, USDT, ETH, or BTC, on a blockchainNetwork of Ethereum, Tron, or Bitcoin.

There is no batch or bulk payout endpoint. A team that needs to pay many recipients in one run uploads a CSV list in the merchant dashboard instead of calling the payout endpoint in a loop from application code. POST /crypto_payouts/estimate returns an estimate for a given amount and asset before you commit to the payout call, and GET /crypto_payouts/balance returns the balance available for payouts.

The payout balance is separate from your main account balance, so a payout needs funds moved into it first. POST /balance/transfer does that:

This moves funds from your main balance into the balance used for crypto payouts. It does not move money to an external recipient by itself; the crypto payout call does that.

Every one of these endpoints creates something before it finishes, so your integration also needs to know what happened after the call returns. EukaPay's webhooks cover both sides: paymentCompleted, paymentUnderpaid, and paymentOverpaid for invoices, refundCompleted for refunds, and cryptoPayoutCreated, cryptoPayoutSent, cryptoPayoutError, and cryptoPayoutRevoked for payouts. A cryptoPayoutSent payload carries the destination amount, the network, and the wallet address:

If a delivery fails, EukaPay retries every 20 minutes for up to two hours before it drops the event from the retry queue. Your endpoint should still treat webhooks as a notification, not a lock. Read the payout or invoice back with a GET call if your own state needs to be certain.

Every one of these calls returns control to your system immediately, and your system still owns what happens next. Idempotency keys, sent as x-idempotent-key, protect a single call from being duplicated on retry. They do not build a ledger for you. Matching a webhook back to the order or payroll line it belongs to stays on your side of the API boundary. So does deciding what a partial or failed payout means for your own records, and keeping your own audit trail.

The same boundary holds one layer down. EukaPay does not issue, mint, or hold reserves for the stablecoins moving through these endpoints, and it does not custody a merchant's treasury. Issuance and custody sit with providers like Circle, Fireblocks, BVNK, Bridge, and Zerohash, a layer below merchant acceptance and payouts. A team building against this API is integrating a payment and payout surface, not adopting a stablecoin issuer or a custodian.

The full crypto payments API, every field on every endpoint described here, sample requests, and the authentication and idempotency headers, is documented at

docs.eukapay.com

. That is the source to read before you write integration code, and the one to keep open while you do; anything a blog post shows is a subset chosen to make one point at a time.

Reading it alongside

the documented endpoints behind those payments

and

the API a stablecoin payments platform exposes

gives a fuller picture of where this API surface sits inside a broader crypto or stablecoin acceptance stack.

Sign up for a EukaPay account to get a test-mode API key and start calling these endpoints in a staging environment. Full request and response detail for every resource in this guide, plus authentication and webhook setup, is at

docs.eukapay.com

. Create your account at

app.eukapay.com/signup

when you are ready to move from staging to a live key.

Is a cryptocurrency payment API the same thing as a crypto payments API?

Yes. Both names describe the same documented resource surface: invoices, subscriptions, customers, payouts, and balance transfer.

Does the crypto payout endpoint support batch or bulk payouts?

No. POST /crypto_payouts creates one payout per request. Paying many recipients in one run is a CSV upload in the merchant dashboard, not a looped API call.

Which cryptocurrencies can a payout send?

USDC, USDT, ETH, and BTC, on the Ethereum, Tron, or Bitcoin networks.

How do I know a payment or payout finished without polling the API?

Subscribe to webhooks. paymentCompleted, paymentUnderpaid, and paymentOverpaid cover invoices; cryptoPayoutCreated, cryptoPayoutSent, cryptoPayoutError, and cryptoPayoutRevoked cover payouts.

How do I fund a crypto payout before I send it?

Call POST /balance/transfer to move funds from your main account balance into the balance used for crypto payouts.

Does EukaPay issue or custody the stablecoins this API moves?

No. EukaPay processes the payment and payout, but does not issue, mint, or hold reserves for any stablecoin, and does not custody a merchant's treasury.

What authentication does the API use?

An x-api-key header, using a key prefixed sk_test_ or sk_live_ depending on environment.

Can I safely retry a request that timed out?

Yes, if you send an x-idempotent-key header with the request. A retry with the same key returns the original result instead of creating a duplicate.