Testing a Crypto Gateway Before Going Live

What does test mode actually prove?

That your code talks to the API correctly. Payments create, webhooks fire, signatures verify, orders move to paid. That is worth having and it is the easy half.

What it does not prove is how the provider behaves when something goes sideways, because most test environments simulate the happy path and little else. The failures that matter involve a real chain, a real wallet and a real amount, and several providers offer no way to trigger them synthetically.

Which live tests are worth running?

Three, all cheap, all before launch rather than after.

A deliberate underpayment of about 2%. Send slightly less than the invoice. Watch what the provider does, what your webhook receives, and what state your order lands in. This is the most common real world exception and the least documented behaviour in the category.

A payment after expiry. Let an invoice time out, then pay it. The customer has sent real money against an order your system has already closed. Find out now whether the provider credits it, holds it, or does nothing.

A wrong network send. Send the right asset over a network the provider does not watch. Learn whether recovery is automatic, manual or impossible, and write the support answer down before a customer needs it.

The integration checklist covers the code these tests exercise.

What should you check on the way out of test mode?

That test and live credentials are genuinely different, and that nothing in your configuration falls back to test silently. A payment flow pointing at test in production fails in the worst way, by appearing to work.

That your webhook endpoint is reachable from the public internet and not behind an allowlist keyed to an IP the provider will eventually change. The webhook guide covers the rest of the handler requirements.

That you have a reconciliation pass running on a schedule and not only the callback path. Callbacks get lost, and the first time you notice will otherwise be a customer telling you.

What does the first day look like?

Watch three things. Webhooks arriving and being acknowledged. Settled amounts matching orders. Whether anybody outside the engineering team can find the settlement report without asking.

That last one sounds trivial and is the most common gap. The person who built the integration understands the dashboard, goes on holiday, and finance discovers it cannot answer a simple question about yesterday.

What if a provider makes this hard?

Treat it as data. A provider whose test environment cannot simulate an underpayment, and whose documentation does not describe the behaviour, has told you something about the next two years. The catalogue records what each provider publishes, and the pattern in that column is a fair predictor of how support conversations go.

Why the live tests cost so little

A few dollars in network fees plus whatever you send yourself, which comes back. Fifteen minutes of somebody’s time.

Set against that: underpayment handling discovered during your first busy week, with a customer waiting and nobody sure what the provider does. The asymmetry is large enough that skipping the tests is difficult to justify on any reasoning except that nobody thought of it.

The checklist for the switch

Test and live credentials separate, with no silent fallback. Webhook endpoint reachable from the public internet, not behind an allowlist tied to an IP that will change. Reconciliation job scheduled and reporting somewhere visible. A runbook for a payment that arrives without a matching order.

And one person other than the developer who can find the settlement report. That last item is the one that gets skipped and the one that causes a problem three months later.

The first week

Watch the callback path and the reconciliation independently. If they agree, your integration is sound. If they diverge, you have found the bug now rather than at quarter end.

Keep the old payment method live if you are migrating rather than starting fresh, and move traffic in fractions. The switching pages cover the migration case in more detail.

What a provider’s test environment tells you

Whether it can simulate underpayment and expiry says something about how seriously the provider takes the exceptions its merchants will actually meet. A test mode that only exercises the happy path is a fair predictor of documentation quality elsewhere.

Where to go next

The integration checklist covers the build these tests exercise, and the webhook guide covers the handler most likely to fail under load. The underpayment entry covers the exception worth testing first.

Documenting what you find

Write down what the provider actually did in each failure case, because it is not in their documentation and it will not be in anyone’s memory in six months.

That document is what your support team answers from, what a future developer reads before changing the integration, and what you compare against if the behaviour ever changes. It takes twenty minutes at the end of testing you have already done, and it is the most reused artefact the whole exercise produces.

What to test again after any change

A provider version upgrade, a credential rotation, or a change to your own checkout. The failure paths are cheap to re-run and they are exactly what a change is most likely to break silently.

Keeping the three test cases as a short written script rather than something somebody remembers is what makes re-running them a ten minute task instead of a project nobody schedules.

The underlying principle is simple enough to state in a sentence. Test mode proves your code is correct; live tests prove the provider behaves as you assumed, and only one of those two assumptions has ever been the expensive one.