From Sandbox to Production: What Integrating a Payments API Actually Looks Like

Every integration looks finished the moment the sandbox turns green. The test payment clears, the webhook fires, and the account gets created. Then production traffic arrives, and things that never happened in testing start happening constantly: a webhook arrives twice, a network blip causes a timeout that leaves an order in limbo, a user closes their browser before the confirmation page loads. None of this means the sandbox lied. It means the sandbox and production are two different environments, and treating a pass in one as proof of readiness in the other is where most integrations actually break.

In this guide, we will explore what a real integration journey looks like end-to-end: getting sandbox access, what to actually test before you trust it, building against the core API flow, going live, and the specific pitfalls that catch experienced teams, not just beginners, when they integrate a cross-border payments API.

How To Get Sandbox Access

Access to a payments API isn’t instant and self-serve for every provider, and for a regulated one moving real money across borders, that’s by design rather than friction. WeWire’s process runs in parallel on two tracks. On the business side, you submit an application, a discovery call confirms your transaction volumes and jurisdictional fit, and, once approved, you receive an onboarding link and submit documentation for verification, often completing within a day of a prompt response. Sandbox credentials typically become available once that initial approval clears, so your engineering team can start building before final production access is fully live.

Test Credentials and What to Actually Test

A sandbox environment is only as useful as what you actually put through it. Teams must validate how their systems behave when transactions fail, remain pending, expire unexpectedly, or trigger delayed updates, not just when everything succeeds on the first try. Testing authentication separately from the happy path matters too: expired tokens, invalid credentials, and missing headers are common causes of failures that only surface once real traffic hits the integration.

Keep sandbox and production API keys in genuinely separate places, ideally in a secrets manager rather than in an environment file that could be accidentally committed to a repository. If a key is ever exposed, even briefly, rotate it before it touches production traffic.

Building Against the Core Flow

Once you’re testing properly, the actual integration follows three steps. Connect and authenticate with your API keys. Create the accounts or sub-accounts your users need, provisioned programmatically as they onboard rather than opening one at a time by hand. Then move money, triggering payouts, collections, or conversions via API calls, with webhooks tracking every state change and feeding into a single reconciliation feed, rather than requiring you to poll separate endpoints for each currency.

This is the same pattern our guide to enhancing digital wallets with virtual IBAN integration walks through for a specific product type, account provisioning and money movement, both driven by the same event-based architecture rather than manual steps a team has to coordinate separately.

Going Live

Before flipping the switch to production, a short checklist matters more than it may seem. Confirm your live API keys are stored securely and separately from sandbox keys. Confirm that your webhook endpoint is registered specifically for the live environment. 

One guide to payment gateway integration flags this exact mistake as common: a sandbox webhook URL accidentally left configured in the production environment, which makes it look like your system is receiving events when it’s actually only receiving test traffic. Run one real, small live transaction end-to-end before trusting the integration with actual customer volume: a successful transfer, a webhook received and processed, and your own system correctly reflecting the result.

Common Integration Pitfalls

This is where the gap between “it works” and “it survives production” actually shows up.

Treating the sandbox pass as proof of production readiness.

Testing guidance for payment gateway integrations puts it plainly: the sandbox passes, the flow looks green, but users don’t live in your sandbox. They switch networks. Banks interrupt flows. Real-world conditions break things that a clean test environment never surfaces.

Non-idempotent webhook handling

Gateways and payment providers retry failed deliveries, so your system may receive the same event more than once. If your handler processes it as a new event each time instead of checking whether that event ID has already been handled, you risk double-crediting an account or double-processing a payout.

Using a redirect or confirmation page as your source of truth instead of the webhook

A user’s browser can close before a redirect completes, even after their payment has genuinely succeeded. Treating the webhook, not the redirect, as the actual confirmation of what happened avoids a whole class of “the customer paid, but the system doesn’t know it” incidents.

Not designing for out-of-order events

In some architectures, a settlement confirmation can arrive before the creation event. A state machine that assumes strict ordering will break the first time reality doesn’t match that assumption.

Slow, synchronous webhook processing

If your webhook handler does real work inline, sending emails, provisioning an account, updating a ledger, and takes too long to respond, providers will interpret the delay as a failure and retry, compounding the exact duplicate-event problem above. Acknowledge fast, then process asynchronously.

WeWire: Built for Developer-First Payments From Sandbox to Scale

WeWire’s architecture reflects developer-first payments at every stage: a sandbox that mirrors production behavior rather than a simplified mock, webhooks firing on every state change across the transaction lifecycle, and account or sub-account provisioning that’s programmatic from the first API call rather than requiring manual setup. 

It’s the same infrastructure processing $3B+ in transaction volume for 3,000+ businesses across countries, spanning established markets like the US, Canada, and the UK, alongside fast-growing corridors elsewhere, so the corridor coverage your integration needs on day one is already in place rather than something you negotiate later.

The Bottom Line

Moving from sandbox to production isn’t a final formality after the code works. It’s the stage where the assumptions your integration quietly made during testing are tested in the real world: duplicate events, out-of-order delivery, timeouts, and users who never see the confirmation screen even though their payment succeeded. Proper sandbox payment testing means deliberately breaking things before your customers do, and a cross-border payments API built to mirror production in its sandbox makes that possible rather than theoretical.