Test credit card numbers for payment testing: every outcome, and what to test besides cards

Test credit card numbers are card numbers that only work in a payment sandbox: they never move money, and each one is wired to a fixed outcome — a successful payment, a decline with a specific reason, or a 3D Secure challenge. With the right test card numbers you can walk through every path a real buyer can take before your integration touches a real card.

Below are the test card numbers KukoPay's sandbox accepts, how to use them, and — just as important — the tests that are not about cards at all: webhooks, refunds, wallets and duplicate requests.

Test credit card numbers that succeed

Use any future expiry date and any three-digit security code (four digits for American Express).

4242 4242 4242 4242 is the number most developers reach for first, and it is the one to use for your "happy path": order created, buyer pays, webhook received, order fulfilled once.

Test card numbers for declines and 3D Secure

After a decline the order stays pending and the same checkout link keeps working, exactly as in live mode; the sandbox adds the code to the message so you can tell which case you hit. What each code means for a real buyer is explained in card decline codes explained, and the verification flow behind 3220 in what is 3D Secure.

How do you use test card numbers?

1. Create a sandbox order with a kuko_test_ key (POST /v1/orders), or click Place test order under Developers → Sandbox testing in the dashboard. The quickstart has the request.
2. Open the checkout_url and choose card. The sandbox form lists the test cards — click one to fill it in.
3. Pay, then check your side: the webhook arrived, the signature verified, the order was fulfilled once.

The key decides the environment: a kuko_test_ key can never create a live charge, and a kuko_live_ key is refused until your account is approved, so test code cannot charge a real card by accident.

Which payment scenarios should you test?

Card numbers cover the buyer's side. A payment integration usually breaks on the server's side, so test these too:

The webhook rows are the ones teams skip and regret: retried deliveries are normal, and duplicate payment webhooks shows how to fulfil each payment exactly once. Equally, never treat the buyer's redirect as the result — return_url vs notify_url.

How to test wallet payments in the sandbox

Alipay, WeChat Pay, PayPal, Apple Pay and Google Pay have no card number to type. In the sandbox, choosing one opens a test authorization page with Authorize payment and Decline payment:

• authorize — the order is paid and payment.succeeded is sent, even if the browser is closed on that page;
• decline — the order stays pending and the buyer can pick another method;
• return to the checkout without choosing — the unfinished payment is cancelled before a new one starts.

How the real wallets behave for buyers is covered in how to accept Alipay and WeChat Pay online.

Testing without opening the checkout

Two tools under Developers let you exercise your server before any buyer flow exists:

• Simulate result on a sandbox order that has not reached checkout: success (with the payment method the buyer "used"), failure or expiry. It runs the real machinery — order status, sandbox balance credited at that method's real fee rate, the event recorded, the webhook delivered and retried — so a simulated success can then be refunded to test refund webhooks too.
• Send test callback sends one request with the same format and signature as a real webhook to an endpoint or URL you choose, and shows both what was sent and what your server answered. Its event id starts with evt_test_ and carries "test": true, and it changes no order or balance — make sure your receiver ships nothing for it.

Testing refunds and payouts with sandbox money

The sandbox wallet opens with $5,000.00 of test funds, so refunds and payouts can be rehearsed end to end; Top up test funds on the wallet page restores it. A sandbox payout completes immediately, with the same ledger entries a live one ends with, so you can practise reconciliation before real money moves. Fees in the sandbox follow the real formula — how cross-border payment fees are calculated works through it.

Going live

When the sandbox passes, switching is only the key: replace kuko_test_ with kuko_live_ on your server. The endpoint, fields, checkout and webhooks stay the same, so everything you tested still holds. The full go-live checklist is in how to accept international payments on your website.

Summary

• Test credit card numbers work only in a sandbox and each one produces a fixed outcome;
• 4242 4242 4242 4242 succeeds, 4000 0000 0000 3220 asks for 3D Secure, and the 4000 0000 0000 … numbers produce specific declines;
• use any future expiry and any CVC, and never a real card;
• test the server side too: duplicate requests, webhook retries, refunds and abandoned checkouts;
• wallets have test authorization pages, and Simulate result and Send test callback test your server without a checkout.