Payment documentation almost always assumes you start with credentials. Create an account, get your test keys, then build. That order works when the provider decision is already made. It doesn't work when building for a client who hasn't set up their gateway yet, or when the provider choice is still open.
A scenario that comes up constantly
A client says they want Stripe. Great — but their Stripe account doesn't exist yet, the kick-off is tomorrow, and a working checkout demo needs to be ready by end of week. The blocker isn't Stripe. It's the client's onboarding queue, which could take days.
Or consider a product targeting markets where PayPal and Razorpay are both viable. Creating two accounts, managing two credential sets, and building two integrations before picking one is unnecessary overhead. Build the integration layer once, get it working against a neutral API, then point it at whichever provider wins the evaluation.
What you need before any account exists
A mocked response in a test file confirms your code builds the right request. But mocked responses won't tell you whether the redirect works, whether your verify logic handles every status, or whether the webhook handler fires at the right moment. For that, you need a real API to send requests to, a hosted checkout page to exercise the redirect, and webhook delivery to a local endpoint.
Pair that with a tunnelling tool like ngrok — which exposes your local server to the internet — and the full payment cycle runs on your laptop before a single external account exists.
What this does to your code quality
Building against a neutral API before picking a provider has a side effect: gateway code stays isolated. Without being locked into one provider's response format from the start, you naturally write a service layer that keeps gateway logic separate from order fulfilment logic. Clients change their preferred processor. Products move into new markets. A well-isolated service layer handles those transitions as configuration changes — not three weeks of refactoring.
Connecting real credentials
Swapping to a real gateway should take one sitting: update the base URL, API key, and webhook secret. Run your existing tests against the real endpoint. Fix anything that breaks due to a response shape difference. If the process takes longer than that, gateway logic has probably leaked into parts of the codebase that shouldn't know about it.
MockGateway's playground is built for this. Pick a gateway template, get a live endpoint, and start building before any account exists.
Tagged with
Found this helpful?
Share it with your network.
