When a gateway has no sandbox, build one yourself

Start from what the real gateway does

Open the provider's API docs and pull out three things: the request it accepts, what it says back straight away, and what it tells you later when you ask how that payment went. To simulate a gateway, those three answers are the whole job. Here they are for XYZ Pay.

POST https://api.xyzpay.com/v1/charge

{
  "merchant_amount": 5000,
  "merchant_currency": "USD",
  "success_redirect": "https://yourapp.com/thank-you",
  "order_ref": "ORDER-1029"
}

{
  "txn_id": "xyz_8f2a1c9b3d",
  "txn_status": "PENDING",
  "checkout_link": "https://pay.xyzpay.com/c/8f2a1c9b3d",
  "amount_charged": 5000,
  "created_ts": 1717000000
}

{
  "txn_id": "xyz_8f2a1c9b3d",
  "txn_status": "PAID",
  "amount_charged": 5000,
  "paid_via": "card",
  "settled_ts": 1717000400
}

Look at the names. XYZ Pay calls the money merchant_amount and the payment txn_id. The next provider will call them something else entirely. Nothing here forces you to rename them, and Step 1 is where that gets handled.

What you get at the end

You write the reply once, with a variable everywhere real data belongs. Every payment then fills those in for you — and you decide, per payment, whether it succeeds or fails.

{
  "txn_id": "{{payment_id}}",
  "txn_status": "{{status}}",
  "amount_charged": "{{amount}}",
  "paid_via": "{{payment_method}}",
  "settled_ts": "{{payment_completion_at}}"
}

{
  "txn_id": "pay_4c1de07a92",
  "txn_status": "success",
  "amount_charged": "5000",
  "paid_via": "card",
  "settled_ts": "2026-02-14T09:31:22Z"
}

Name it XYZ Pay, set the currency, and give it a default redirect URL. That URL is the fallback — MockGateway uses it whenever a request arrives without one of its own.

Step 1 of 3

Now add one field for each thing XYZ Pay accepts. Type the name exactly as the provider writes it, pick the type, and attach the rules — required, min:1, size:3. Anything that breaks those rules comes back as a validation error, the same as it would on the real thing.

{
  "merchant_amount": "required|integer|min:1",
  "merchant_currency": "required|string|size:3",
  "success_redirect": "required|url",
  "order_ref": "nullable|string|max:100"
}

Shortcut: paste the provider's own example request into Import from JSON and every field above is created for you, types guessed from the values.

Your fields can be called anything, so one question has to be answered directly: which of them holds the money? Answer it here, and answer the redirect question too if your request carries its own return URL.

This is the one step people skip, and it is the one everything downstream leans on. The checkout page reads the amount from the first answer. The customer comes back to your site using the second.

Shortcut: click the small tag icon inside either box to pick a field from the list instead of typing the braces by hand.

Scroll back to XYZ Pay's two replies at the top of this page and write them out again here, key for key. Wherever the provider would put real data, put a variable instead.

{{payment_url}} turns into the checkout link. {{status}} turns into whatever the payment ended up as. Keep every other key spelled the way the provider spells it, and the code in your app that reads the response never has to change.

{
  "txn_id": "{{payment_id}}",
  "txn_status": "{{status}}",
  "checkout_link": "{{payment_url}}",
  "amount_charged": "{{amount}}",
  "created_ts": "{{payment_request_at}}"
}

{
  "txn_id": "{{payment_id}}",
  "txn_status": "{{status}}",
  "amount_charged": "{{amount}}",
  "paid_via": "{{payment_method}}",
  "settled_ts": "{{payment_completion_at}}"
}

{
  "txn_id": "{{payment_id}}",
  "txn_status": "{{status}}",
  "checkout_link": "{{payment_url}}",
  "amount_charged": "{{amount}}",
  "created_ts": "{{payment_request_at}}"
}

{
  "txn_id": "{{payment_id}}",
  "txn_status": "{{status}}",
  "amount_charged": "{{amount}}",
  "paid_via": "{{payment_method}}",
  "settled_ts": "{{payment_completion_at}}"
}

Do not skip this one: the start reply needs {{payment_url}} somewhere in it. That is the link you send the customer to, and without it a payment has nowhere to happen.

Built-in payment outcomes

Custom gateways provide succeeded, failed, and canceled outcomes. Pending is the initial payment state. These outcomes are fixed; select one on the hosted checkout when testing.

Configure your webhook on the Webhooks page and attach it to the gateway. Each event is delivered once and its result is logged.

The final screen counts back what you built — how many fields, which currency, how many outcomes — and gives you one button. Press it and XYZ Pay exists.

• Check the field count and currency before you launch — both are quick to get wrong
• Webhook and gateway settings remain configurable; payment outcomes are fixed
• Run your first payment from the Integration tab, covered next

Open the Integration tab for the base URL and the API key. Every gateway you build from scratch answers on the same two paths.

A live gateway page — different gateway, same screen

Send the fields you defined in Step 1 and it answers for real:

curl -X POST https://mockgateway.com/api/base/xyz-pay/init \
  -H "Authorization: Bearer sk_test_xxxxxxxx" \
  -H "Content-Type: application/json" \
  -d '{
    "merchant_amount": 5000,
    "merchant_currency": "USD",
    "success_redirect": "https://yourapp.com/thank-you"
  }'

Variables you can use

These work in response templates, redirect URLs, and webhook bodies. Wrap the name in double curly braces: {{variable_name}}

Request-input variables follow your own schema, so yours will differ. amount and currency above are only examples.

Questions that come up