Testing

In test mode no money moves and there is no payer to pay. Instead, the UTR a test payment is confirmed with decides what happens to it next: some UTRs are magic and take the payment to a status of your choice, the way test card numbers do at other payment providers. You confirm a test payment as you would a live one:

• with POST /payments/{id}/confirmations, passing on the UTR as your payer would give it to you, or
• on our hosted payment page, typing the UTR into the payer’s “I have paid” form.

Without a line of code, the portal does both for you: Developers › Checkout › Open test checkout, or Create test payment over Payments in test mode, makes a test payment, opens your page on it, and its Simulate buttons confirm it with each magic UTR below.

Magic UTRs

UTR	What happens
000000000001	processing, then succeeded at once.
000000000002	processing, then failed 24 hours later: the money never came.
000000000003	processing, then failed 5 seconds later.
000000000004	processing, then succeeded at once, paid 1.00 less than asked: amount_paid and amount_credited are what was paid, not amount_payable, and amount_mismatch is true.
000000000005	Stays awaiting_payer until it expires, then expired, then succeeded 5 seconds later: a late payment.
000000000006	Stays awaiting_payer until it expires, then expired, then failed 5 seconds later.
Any other 12 digits	processing, then succeeded 5 seconds later.

“At once” means within a second or two: read the payment again to see it.

A test payment that fails in 5 seconds

curl https://api.63-180-91-99.sslip.io/payments/pay_in_01J9…/confirmations \
  -H "Authorization: Bearer sk_test_in_…" \
  -H "Content-Type: application/json" \
  -d '{ "utr": "000000000003" }'

The answer is the payment, processing; read it again with GET /payments/{id} and it is failed.

How they behave

• The first confirmation decides. A payment confirmed with a second UTR, by you or by the payer, keeps the path of the first: one that 000000000005 or 000000000006 keeps waiting for the payer stays waiting until it expires, and our page shows the payer their UTR being checked.
• Any number of payments. A magic UTR is not a real transaction, so you can confirm every test payment with it. Any other UTR confirms one payment, as in live mode: on a second payment it is 409 reference_already_used.
• In Argentina, send them as coelsa_id. A transfer is confirmed with the COELSA id on the payer’s receipt, not a UTR: the same magic values, sent as coelsa_id, take a test transfer down the same paths.
• Wrong UTRs are refused as in live mode. One that is not 12 digits is 400 parameter_invalid.
• Everything else is real. The payment’s statuses, its amounts and, once they are here, its webhooks are the ones a live payment gets on the same path. A test payment that is never confirmed expires at its expires_at and fails 24 hours later, as a live one does.
• Live mode has no magic. With a live key these are ordinary UTRs, and none of them is paid unless its money arrives.
• Test payments are kept 90 days. A test payment, and its page, is deleted 90 days after it was created: GET /payments/{id} answers 404 from then on. Live payments are kept.

Rate limits

Test mode allows 25 requests a second per test key and 100 per account; a request over either is 429 rate_limit. See Rate limits.