Nobody reads the full API documentation before starting. There's usually too much of it, and half describes edge cases that won't apply here. So developers make reasonable guesses: the status field is probably status, the payment ID is probably payment_id, the amount is probably a number. Testing the payment gateway API in Postman first is the fastest way to find out which guesses are wrong before any code depends on them.
Why payment API assumptions lead to rewrites
A payment integration has three distinct steps, each returning a different response shape. The init call returns a checkout URL and a reference token. The verify call — made after the user returns from the payment page — returns a transaction record. The webhook delivers a separate event to your server, independent of the redirect.
Most developers model all three as variations of the same structure. They're not. The status field can sit at the top level in one response and nested two levels deep in another. The reference linking all three calls together might use a different key name in each. Finding this while writing code means rewriting it. Finding it in Postman before starting means nothing needs to change.
Download the collection — MockGateway builds it for you
Building a Postman collection from scratch means reading documentation, guessing at request bodies, and manually wiring the payment ID between requests. MockGateway skips all of that. Once a gateway is created, the Postman collection is ready to download directly from the gateway page — init request, verify request, and webhook example already configured for that gateway's exact structure.
Import it, add your API key as an environment variable, and run. The init response captures the transaction ID automatically and passes it into the verify request. No copying values between requests, no placeholder editing.
Postman's job here isn't configuration — it's a window into what the API actually returns before a line of code is written.
What to check in each response before writing code
Start with the init response. Is the checkout URL field where you expected it? Check whether there's a separate order reference to store before the redirect — it often has a different key name than you'd assume.
The verify response is usually the most surprising. That status field might return five or six values, not just "success" or "failed". Check whether the amount is a number or a string — some providers send "1500", not 1500. Easy to miss until it breaks a comparison.
The webhook payload is its own shape entirely. What is the event type field called? Is there a signature header? Does the ID format match the verify response, or will your handler need to normalise it? Mismatches break the lookup silently. The webhook handling guide goes deeper on that.
None of these are hard to answer. You just need a real response in front of you.
One collection file that documents the whole integration
Commit the downloaded collection to the repository alongside the code. When a new developer joins and asks how the payment flow works, the answer is: import this file and run the three requests in order. That takes five minutes and always reflects what the API actually returns.
When the payment provider changes, download the new collection and import it. If you haven't settled on a provider yet, building the integration before credentials exist is a practical approach — Postman and a mock gateway get the flow working before any account is needed.
Create a free gateway on MockGateway to download the Postman collection for your chosen provider, or use the playground to explore the payment API without an account.
Tagged with
Found this helpful?
Share it with your network.
