Skip to main content
Before going live, exercise the full payment flow in a sandbox. Quidkey routes test payments to a sandbox provider so you can integrate, verify webhooks, and rehearse edge cases, with no real bank movement.

Route a Payment to the Sandbox

Pass test_transaction: true when you create a payment. Quidkey routes it to the sandbox provider instead of a live bank connection.
Body abbreviated. See the Redirect guide for the full required payload.
Always set test_transaction: true in development. A request without it is treated as live and may attempt a real bank movement.

Identifying Test Events

Webhooks for sandbox payments carry test markers, so your handler can tell sandbox traffic apart from production. The event payload includes a test flag (and sandbox indicators) on the payment object:
Gate your fulfilment logic on data.object.test. In non-production environments, ignore live events; in production, ignore test events. This prevents a stray sandbox webhook from triggering real fulfilment.

Sandbox vs. Live

If your account provides separate sandbox credentials and a separate webhook signing secret, use them for test traffic and keep them distinct from production. This keeps environments cleanly isolated.

A Typical Test Pass

1

Create a test payment

Create a payment request with test_transaction: true and complete it through the sandbox flow.
2

Confirm the webhook arrives

Verify your endpoint receives the event, the signature validates, and data.object.test is true. See Webhooks.
3

Exercise edge cases

Test failure and cancellation paths, and confirm your idempotency and error handling behave as expected.
4

Reconcile

Look up the payment via the status endpoint to confirm your records match Quidkey’s.

Next Steps

Webhooks

Verify signatures and handle test events

Accept a Payment (Redirect)

Create your first test payment

Amounts & Currencies

Send amounts correctly in tests

Errors

Test your error handling paths