Frequently Asked Questions

MockGateway gives you fake payment gateways that behave like real ones. You call an API, get back a checkout link, pick what should happen on that page, and your server receives a webhook. No real money moves, and you never need an account with an actual payment provider.

Developers use it to build a checkout, QA teams use it to run the same set of payment outcomes before a release, and automation folks wire it into their pipelines. The docs go through it properly if you want the longer version.

Three groups, mostly. Developers wiring up a checkout for the first time. QA engineers who need a decline to decline the same way every single run. And whoever looks after the test pipeline and is tired of it going red because a sandbox was down.

If you have ever waited days for a sandbox account before you could write a line of code, that is the problem we started with.

No. It is for development, QA and staging. Build and test against it, then point your code at the real provider when you are ready to take actual payments. Nothing here can move money, so it would not work anyway.

None. We are not connected to a bank or a card network at all. Every amount you see is a number on a test record, and every result is one you chose yourself.

Under a minute if you start from a template. Pick Stripe or PayPal, hit create, and you have a live endpoint with a checkout page and working webhooks. Building a custom gateway with your own field names takes a few minutes more.

The quickstart walks the whole thing end to end.

Sign up, then create a gateway. Each one comes with its own key, like sk_test_xxx on the Stripe template, and it goes into your config exactly where the real key would.

See creating a gateway from a template.

When you set up a gateway you also list its outcomes: success, decline, 3DS, whatever you need. You get a checkout URL back. Send someone there, they pick an outcome, and we bounce them to your return URL with the right query parameters and post a webhook to your server.

Same shape as a real provider, which is the point. Manual testers can click through it; your test suite can skip the page entirely. The quickstart shows both.

There are ready-made templates for Stripe, PayPal, Razorpay, Braintree, Adyen, Square, Mollie, Authorize.Net, Checkout.com, Worldpay, Helcim, Skrill, Payoneer and 2Checkout. You can see them all on the gateways page.

If yours is missing, build a custom one with your own fields.

As many as you need, even on the free plan. One per provider, one per environment, one per branch if that helps. The monthly limit counts payment requests, not gateways.

Build it yourself. You decide what the request looks like, what each endpoint returns, which outcomes testers can pick, and what the webhook body contains. Anything a real provider does over HTTP, you can copy.

Start with building a custom gateway.

A scenario is one thing that can happen to a payment. Success, card declined, not enough funds, timeout, cancelled, still pending settlement. Each has its own status code, response body, redirect parameters and webhook.

This is the part QA teams tend to live in. Write your list of cases once and you can run the same failures before every release, instead of hoping a sandbox gives you a decline when you need one.

Yes. Response templates use variables, so you control the exact JSON your code receives from both endpoints. Field names, nesting, status codes, error shapes, all of it. That matters when you are matching a provider's quirks rather than a tidy example.

See the Init and Verify endpoint reference.

No. The free plan gives you 500 test payment requests a month, all 14+ gateway templates, webhooks and the full API. There is no card form anywhere in signup and no trial clock counting down.

Here is how to create your account.

Yes. We send a real HTTP POST to whatever URL you set, with proper headers, a JSON body and the right status codes. Every attempt is saved along with your server's reply, so you can go back and look at it.

Here is how to set one up.

Not directly. We post from the internet, so a plain localhost URL is not reachable. Use ngrok or a Cloudflare Tunnel, the same as you would with a real provider. Either way the attempt is logged, so you can still see what we sent when your endpoint is down.

See testing webhook connectivity.

Yes, and you switch it on per gateway. Verify the signature in your handler the same way you would in production. It means that code actually gets exercised, instead of being the one branch nobody runs until launch day.

We keep the failure, with the status code and the body your server sent back. Handy for the classic bug where the webhook arrives before your order row has been committed. Turn your endpoint off on purpose and you can watch it happen.

More in testing webhook connectivity.

Yes. Every delivery is stored with its payload, headers, response and timing, and it stays in your dashboard. When a nightly run goes red, the log tells you quickly whether the callback was wrong or your handler was.

Anything that can make an HTTP request. There is no SDK to install. Plain REST from PHP, Python, Node, Ruby, Java, Go, or from Postman and k6 if you are testing rather than building.

Yes, that is one of the main reasons people use it. It is an ordinary REST API, so GitHub Actions, GitLab CI, Jenkins or a cron job can all drive it. Results do not drift between runs, so a red build means your code changed rather than someone else's sandbox wobbling.

Yes. A scenario returns the same status code, the same body and the same webhook on every single run. That is what makes it usable in an automated suite. A real sandbox will happily time out on you halfway through a release.

Yes. The checkout page is there for clicking through by hand, but every outcome is reachable over the API too. So a suite can take a payment from init through to the webhook without ever opening a browser.

The endpoint reference has the calls.

In the documentation. Endpoints, auth, scenarios and webhook payloads are all there. If you would rather just try it, the playground runs a full payment without an account.

500 test payment requests a month, all 14+ gateway templates, real webhooks with their logs, your own response formats and hosted checkout pages. No card, no trial window, and no features held back.

Full details on the pricing page.

One payment started through a gateway you own is one request, however many webhook retries or verify calls follow it. Creating gateways, editing scenarios and reading logs are all free.

New requests come back with a clear error until the count resets on the first of the next month. Nothing is deleted, nothing is charged, and your gateways keep every bit of their setup.

Still being built, and you cannot buy either of them yet. We do not collect card details anywhere on the site today. Leave your address on the pricing page and we will write to you before anything changes. The free plan stays free.

No. Nothing here processes a payment, so there is nothing to store. Please do not type a real card number, real bank details or a live provider secret key into it either. Treat every field on the site as a test field.

Your account details, the gateways and scenarios you set up, and the test payments and webhook logs they create. The privacy policy lists each type and how long we keep it.

No. Gateways, payments and logs belong to your account only. Checkout URLs are hard to guess, but they are still links. Anyone holding one can finish that particular test payment, so treat them the way you would any shared URL.

Not properly yet. An account belongs to one person, so today sharing a login is the only way to share gateways, which we know is not good enough for a QA team. Shared workspaces with a role for each member are what Pro Plus is being built for.

Ask us from your profile settings or through the contact page and we will remove the account with its gateways, payments and logs. It cannot be undone, so export anything you still want first.

See managing your account for what you can change yourself.