How to test stablecoin payments before going live

A step-by-step rehearsal for the stablecoins or crypto payment flow you are about to ship, run entirely on testnet funds.

A card integration gives a developer (or coding agent) a short list of things to test. The charge succeeds, the charge is declined, the refund lands. Stablecoins or crypto add cases that have no card equivalent: a customer who sends 90% of the invoiced amount, a customer who sends 110%, a webhook that arrives twice, and a blockchain confirmation that takes longer than the checkout session.

Every one of those cases can be rehearsed before a single real dollar moves. This guide covers how to test stablecoin payments on EukaPay's staging environment using testnet coins, which webhook events to assert against, and what to change on the day you switch to production.

With cards, the network abstracts the settlement away from the integration. The developer sees an authorisation and a capture. With stablecoins or crypto, the customer controls the transfer, so the amount and the timing are both outside the merchant's control.

That difference produces three failure modes worth rehearsing. A customer can send less than the invoiced amount, because they subtracted the network fee from the total instead of adding it. A customer can send more, because their wallet rounded up. And a customer can close the browser tab after broadcasting the transaction, which means your order state has to be driven by a webhook rather than by a redirect.

There is no chargeback path to correct any of these after the fact, so the correction has to be built into the integration. Testing is where you find out whether it is.

EukaPay runs two environments. Production is at

and staging is at

. The staging environment uses the same exchange rates as the production environment, so the fiat amount your test invoice quotes is the amount a real invoice would quote at that moment.

Staging accounts are created at

. You will not receive a verification email after signing up on staging. EukaPay approves staging registrations manually, so email support@eukapay.com once you have completed the sign-up form and the account will be enabled.

The staging account has its own dashboard and its own API key. Issue the key from the integrations settings inside the staging dashboard, and keep it in a separate secret from your production key. Every request in this guide uses the staging base URL and the staging key.

In your code, the two environments should differ by the base URL and the key alone. Read both from configuration rather than hard-coding either one. Doing so is what makes the go-live step at the end of this guide a configuration change instead of a code change.

Payments on staging are made with testnet cryptocurrencies. EukaPay documents the network for each asset and links to public faucets for the ones that have them. The faucets below are not maintained by EukaPay, so use them at your own risk.

The two stablecoins are the ones most merchants care about, and neither has a public faucet. Request test USDT and USDC from EukaPay support at the start of the integration rather than on the day you plan to test, so the coins are already in your wallet when you need them.

You also need a wallet that can hold testnet balances. MetaMask handles Sepolia once you switch networks in settings. Coinomi creates dedicated testnet wallets when you add a coin such as "Bitcoin Test" or "Litecoin Test". The EukaPay documentation lists the testnet token contract addresses for USDT and USDC on Sepolia and USDC on Shasta, which you will need to add the tokens to a wallet manually.

Create the invoice through the invoices API, which returns a payment page URL. Send your customer to that URL, or open it yourself in a browser to act as the payer. If you pass a

when creating the invoice, the payment page returns the customer to your site once the payment completes.

Each row below is a scenario, the way to trigger it on staging, and the webhook event that should arrive as a result.

An eighth event,

, is sent when an error occurs during the creation or processing of a crypto payout. Handle it even though you cannot reliably force it on demand.

Whether a payment counts as complete, underpaid or overpaid depends on the transaction tolerance settings on your account. Set those in the dashboard before you run the test, otherwise a deliberately short payment may still arrive as

and you will conclude your handler works when it has not been exercised.

The

payload carries both

and

. The first is the fiat amount of the single payment that just arrived, the second is the sum of all payments against that invoice. A customer can top up an underpaid invoice with a second transfer, so your handler should compare

against

rather than treating each payment as final.

Crypto payouts are sent in USDC, USDT, ETH and BTC, across the Ethereum, Tron and Bitcoin networks. The asset and network are set per payout, so a single run can pay different recipients different assets on different networks. Test at least one stablecoin payout and one native-asset payout, because the amount precision differs between them.

The

payload includes a

. Assert that your system stores it against the payout record, since the transaction hash is what your finance team will use to answer a recipient asking where their money is.

Most integrations that fail in production fail at the webhook handler rather than at the API call. Four things are worth testing directly.

EukaPay signs every webhook with an

header. To verify it, compute an HMAC SHA-512 hex digest over the raw payload bytes using your secret key, then compare that digest against the header value. Compute it over the raw body, before any JSON parsing or re-serialisation, because re-serialising changes the bytes and the digest will not match.

Test the negative case as well. Send your endpoint a payload with a deliberately wrong signature and confirm it is rejected.

If a delivery fails, EukaPay retries every 20 minutes for up to two hours before removing the event from the retry queue. Take your staging endpoint offline, trigger a payment, bring the endpoint back up, and confirm the event arrives and is processed correctly.

Two hours is the full window, so an outage longer than that leaves you reconciling from the API instead. Build that reconciliation path before launch rather than after your first incident.

A retry can arrive after your handler already succeeded but before EukaPay recorded the success. Every payload carries a

that uniquely identifies the event. Store processed

values and make your handler ignore repeats. Test this by replaying the same payload twice and confirming your order is fulfilled once.

Do not assume events arrive in the order they occurred. A handler that fulfils an order on

should behave correctly even if a

for the same invoice arrives afterwards.

The EukaPay API uses conventional HTTP response codes. A 4xx means the request failed on the information provided, and a 5xx means the error is on EukaPay's side. Errors carry a

, a

, and a

that is one of

,

or

.

Run these deliberately on staging:

The idempotency test is the one most integrations skip and most need. Simulate a timeout on your side after the request was sent, retry with the same key, and confirm you end up with one invoice rather than two.

Moving to production is a configuration change if you built it that way. Work through the list below in order.

Note that production access requires completing onboarding and verification with your legal business information, so start that process alongside the integration work rather than after it.

Whether the integration takes pay-ins, sends payouts, or both, the same platform carries it: instant crypto-to-fiat conversion at a locked exchange rate to remove all crypto volatility, and settlement in USD, EUR, GBP, CAD to your bank account. A crypto payment settles on-chain, so protection against chargebacks is a property of the payment method rather than a setting you configure.

Pay-ins accept the wider asset set, including BTC, ETH, USDT, USDC, BCH, LTC, SOL and Lightning. Payouts are sent in USDC, USDT, ETH and BTC. The testing work above is what turns those capabilities into a flow you can trust on launch day, because every branch has been exercised with coins that cost nothing.

Read the API documentation at

docs.eukapay.com

to see the invoice, payout and webhook endpoints in full, including sample cURL and NodeJS calls and a Postman collection. When you are ready to build,

create your EukaPay account

and complete onboarding so your production key is waiting when the integration is finished.

Does EukaPay have a sandbox or test environment?

Yes. EukaPay runs a staging environment at

, with its own dashboard at

, where you can take payments in testnet cryptocurrencies.

Do staging exchange rates match production?

Yes. The staging environment uses the same exchange rates as the production environment, so the fiat amounts you see while testing are the amounts a live invoice would quote.

How do I get test USDT or USDC?

Neither testnet stablecoin has a public faucet in EukaPay's documented list. Email support@eukapay.com to request test coins, and do it before you plan to test rather than on the day.

Do I need a separate account for staging?

Yes. Sign up at

, then email support@eukapay.com, because staging does not send a verification email and registrations are approved manually.

How do I verify a webhook actually came from EukaPay?

Compute an HMAC SHA-512 hex digest over the raw webhook payload using your secret key, then compare it to the

header. Use the raw bytes, not a re-serialised JSON object.

What happens if my endpoint is down when a webhook fires?

EukaPay retries the delivery every 20 minutes for up to two hours, then removes the event from the retry queue. For outages longer than that, reconcile against the API.

How do I avoid creating a duplicate invoice when a request times out?

Send an

header with a V4 UUID on every POST and PUT. A retry with the same key returns the stored result instead of creating a second record. Keys expire after 24 hours.

Which assets can I test payouts with?

Crypto payouts are sent in USDC, USDT, ETH and BTC on the Ethereum, Tron and Bitcoin networks, so test with testnet versions of those assets.