A sandbox payment gateway with a real API. Trigger declines, 3D Secure challenges, timeouts and signed webhooks on demand. No real money and no real cards, ever.
200 test payments a month. No email needed. By creating a key you agree to the Terms of service and the Privacy policy.
Permanently deletes this key, your stored payments and your webhook. An active Pro subscription is cancelled. This cannot be undone.
Responses appear here.
Create a key, pick an outcome and send a payment. Card outcomes are chosen by the test card number, exactly like the list under "Test cards" below.
Run a 3-D Secure authentication and read the whole message log, step by step: who talks to whom, what each message contains, and what it means for you as a merchant. This is a teaching simulation. Field names follow the EMV 3DS 2.x specification, but the messages are simplified and every value is made up.
Create or paste an API key above to run the lab.
Pick an outcome and run it. The message log appears here, and your earlier 3-D Secure payments also have a "3DS log" button in the payments table.
| 3DS Server | Software run by the merchant or its provider. It starts the authentication and talks to the card network. |
| Directory Server (DS) | The card network's switch (Visa, Mastercard and others). It finds the right issuer for a card and passes messages on. |
| ACS | Access Control Server, the issuer's system. It judges the risk and runs the challenge. |
| Issuer / acquirer | The issuer is the cardholder's bank. The acquirer is the merchant's bank, which sends the payment for authorisation. |
| AReq / ARes | Authentication Request and Response. The 3DS Server asks the issuer to authenticate, the issuer answers with a transStatus. |
| CReq / CRes | Challenge Request and Response, exchanged between the customer's browser and the ACS during a challenge. |
| RReq / RRes | Results Request and Response. After a challenge, the ACS reports the final outcome to the 3DS Server. This is the message to trust. |
| Frictionless / challenge | Frictionless: the issuer approves in the background. Challenge: the customer must prove who they are, for example with a code. |
| transStatus | Y authenticated. N denied. U could not be performed. A attempt recorded. C challenge required. R rejected by the issuer. |
| ECI | Tells the networks how the cardholder was authenticated. Visa: 05 authenticated, 06 attempted, 07 not authenticated. Mastercard: 02, 01, 00. |
| CAVV / AAV | The cryptographic proof of authentication (Visa calls it CAVV, Mastercard AAV). It travels with the authorisation request. |
| Liability shift | When a payment is properly authenticated, responsibility for "the cardholder did not make this purchase" fraud chargebacks moves from the merchant to the issuer. |
Register a URL and Zanboxx posts a signed event whenever a payment succeeds or fails. Failed deliveries are retried after 2, 10 and 30 seconds.
No deliveries yet.
const crypto = require("crypto");
function verify(rawBody, header, secret) {
const [t, v1] = header.split(",").map((p) => p.split("=")[1]);
const expected = crypto.createHmac("sha256", secret)
.update(`${t}.${rawBody}`).digest("hex");
const fresh = Math.abs(Date.now() / 1000 - t) < 300;
return fresh && expected.length === v1.length &&
crypto.timingSafeEqual(Buffer.from(expected), Buffer.from(v1));
}
// header: req.headers["x-dryrun-signature"], body: the raw request text
With a card payment, the card number decides the outcome. Any other 16-digit number is declined. Follow-up transactions and non-card methods are approved unless you force an outcome.
| Card number | Result | Code |
|---|---|---|
| 4111 1111 1111 1111 | Approved | SBX-2000 |
| 4000 0000 0000 0002 | Declined by issuer | SBX-4002 |
| 4000 0000 0000 9995 | Insufficient funds | SBX-4051 |
| 4000 0000 0000 0069 | Card expired | SBX-4054 |
| 4000 0000 0000 3000 | 3D Secure, frictionless approval (transStatus Y) | SBX-2000 |
| 4000 0000 0000 3220 | 3D Secure challenge (HTTP 202, then confirm) | SBX-2020 |
| 4000 0000 0000 3238 | 3D Secure, frictionless denial (transStatus N) | SBX-4030 |
| 4000 0000 0000 3253 | 3D Secure, attempt recorded (transStatus A) | SBX-2000 |
| 4000 0000 0000 3261 | 3D Secure unavailable (transStatus U), approved without liability shift | SBX-2002 |
| 4000 0000 0000 3279 | 3D Secure rejected by the issuer (transStatus R) | SBX-4032 |
| 4000 0000 0000 0408 | Gateway timeout (HTTP 504, resolves by webhook after about 3 s) | SBX-5040 |
Create a key above, then call the API from your own code. Every request needs the header Authorization: Bearer sk_test_.... Reusing a request_id is rejected, like on a real gateway.
# create a payment
curl -X POST /v1/payments \
-H "Authorization: Bearer $KEY" -H "Content-Type: application/json" \
-d '{"request_id":"order-1001","method":"card","transaction_type":"purchase",
"amount":49.90,"currency":"EUR","card_number":"4111111111111111"}'
# refund part of it
curl -X POST /v1/payments \
-H "Authorization: Bearer $KEY" -H "Content-Type: application/json" \
-d '{"request_id":"refund-1","method":"card","transaction_type":"refund",
"amount":10,"parent_transaction_id":"tx_..."}'
# complete a 3D Secure challenge
curl -X POST /v1/payments/tx_.../3ds \
-H "Authorization: Bearer $KEY" -H "Content-Type: application/json" \
-d '{"result":"approve"}'
Methods: card, paypal, ideal, sepa. Transaction types: purchase or debit, authorization, capture-authorization, refund, void. Currencies: EUR, USD, GBP. Optional scenario: auto, approve, decline, timeout, 3ds.
The free plan is all you need to build and test a checkout.