The CI build was green. It had been green for six weeks. Then a developer pulled the payment logs and found that every test in the PaymentService suite had been skipped since the sandbox credentials rotated in March. Nobody noticed. The build stayed green because skipped tests don't fail.
The checkout flow had a bug in it the whole time. Payment gateway testing was in the pipeline — it just wasn't running.
Why payment gateway tests stop getting fixed in CI
A test that fails randomly teaches your team to ignore failures. After the third time a red build turns out to be a sandbox outage rather than broken code, someone marks those tests non-blocking. After that, they might as well not exist.
The problem isn't that sandboxes go down. It's that when they do, the team learns the wrong lesson — that payment test results aren't worth checking. That attitude is harder to reverse than a credential rotation.
What reliable CI payment testing actually requires
The same request needs to return the same response, every time. Not "usually the same" — exactly the same. A decline scenario returns the expected decline code. A success scenario returns a transaction record in the exact shape your handler reads. No dependency on an external server. No credentials that expire between Tuesday's build and Wednesday's.
When tests are this predictable, a red build means one thing: the code broke. That's the only signal a pipeline should send.
One config change: point tests at a mock gateway
MockGateway gives each gateway a fixed endpoint the moment it's created. In your test environment, swap the base URL to point there instead of the real provider:
PAYMENT_BASE_URL=https://mockgateway.com/api/your-gateway-slugNothing else changes — same test code, same assertions, same expected outcomes. Scenarios are already set up: success returns success, decline returns exactly the code your handler expects. No test card lookup. No secret to rotate between environments.
The demo playground requires no account. For a permanent test gateway with saved scenarios, a free account takes under two minutes to set up.
What belongs in CI — and what to save for pre-launch
Pipeline tests should own the scenarios your application logic depends on for every commit: the successful flow, each decline type that produces a different user-facing message, webhook duplicate prevention, and pending state transitions. These scenarios are stable, have clear pass/fail criteria, and are worth catching before code reaches main. If you're still working out which scenarios to cover, the payment gateway testing checklist is a good reference.
Provider-specific behaviour — undocumented fields, regional card quirks, 3DS challenge flows — belongs in a focused manual pass against the real sandbox in the days before launch. These don't change between commits and don't need to block a merge.
A payment test suite your team trusts is one that runs the same way every time and goes red only when something in the code actually broke. MockGateway's playground is the fastest way to set that up.
Tagged with
Found this helpful?
Share it with your network.
