Testing a Crypto Payment Integration Before You Go Live
The happy path will work on the first try. Spend your time on the eleven cases that will not, because those are the ones that reach your customers.
Your first test payment will work. That is not reassuring, it is expected. The happy path is the easy part and it is not where integrations fail.
What follows is the list worth spending your afternoon on.
Get the environments straight first
Staging is dash-t.aio.cash, API at api-t.aio.cash/v2. Production is dash.aio.cash, API at api.aio.cash/v2. The calls are the same in both, which is what makes the switch safe.
Build entirely against staging. Do not "just try it in production quickly".
The happy path, once
Create a payment, pay it, watch the callback arrive, confirm the order moved and the amount recorded matches. Ten minutes. Then move on.
The eleven that matter
Money cases
- Underpayment inside tolerance. Should complete without a human.
- Underpayment outside tolerance. Should hold, and the customer should be able to top up.
- Overpayment. Should follow your rule rather than sitting unresolved.
- Two payments for one invoice. Both land. What does the order do?
- An unconfigured token. Should be recorded and recoverable, not lost.
Timing cases
- Payment after the quote window expires. Revalued, and your tolerance should absorb it.
- Customer abandons and pays an hour later. Does the order still exist?
Callback cases
- Forged signature. Must be rejected with no side effects. Test this by hand.
- Duplicate delivery. Must be a no-op, not a second fulfilment.
- Out-of-order states. An order must not move backwards.
- Your endpoint down for five minutes. Do the retries recover it, and does reconciliation catch what they miss?
Load, briefly
Fire a hundred callbacks at your endpoint. If the handler is doing work before acknowledging, you will see the retry storm immediately and you will have found a real bug in about a minute.
The go-live checklist
- No staging host or test key left anywhere in the code.
- Production webhook endpoint registered and reachable from outside.
- Production signing secret set, and different from staging.
- Reconciliation scheduled and confirmed running.
- Alerts on callback failures and on payments stuck in a pending state.
- One small real payment taken before customers see the flow.
That last one catches more than the previous five combined.
Frequently Asked Questions
How do I test a crypto payment integration?
Build against staging, take a full test payment end to end, then deliberately test the failure cases: underpayment, overpayment, late payment, duplicate callback, forged signature and an unconfigured token. The happy path rarely breaks; those cases do.
What is the staging environment for AIO?
Staging runs at dash-t.aio.cash with its API at api-t.aio.cash/v2. Production is dash.aio.cash with api.aio.cash/v2. The calls are identical, so going live is a change of host rather than a rewrite.
How do I test a webhook signature failure?
Send a request to your own endpoint with a deliberately altered signature and confirm it is rejected with no side effects. If your order still moves to paid, your verification is not running before your business logic.
What should I check before switching to production?
That no staging URL or test key remains in the code, that the webhook endpoint is registered for production, that the production secret is set and different, that reconciliation is running, and that you have taken one small real payment before opening the flow to customers.