Skip to main content
Ringup’s test mode is built in from the first request: call the API with your rk_test_ key and every payment runs against Ringup’s test processor account. No merchant signup, no processor OAuth, and no real money. Every integration tests against it.

​
The test card

Every test payment runs on one card. When a test-mode call texts a pay link, or when you open a test-mode Checkout page, enter this card:
To test a declined payment, use 4000 0000 0000 0002. It always declines, so you can exercise your failure path and the checkout.failed webhook.
This card is test-mode only. It never reaches a live payment processor and never moves real money.

​
Test merchants

Create a test merchant in the dashboard, under Merchants. In test mode every merchant you create is automatically backed by Ringup’s test processor account, so it is chargeable the moment it exists: no merchant signup, no processor OAuth. Use its mch_ id wherever an example asks for a merchant id. A merchant id Ringup does not know is a merchant_not_found error, not a quiet no-op. A merchant that exists but has connected no processor is the quiet case: the session returns payment_required: "none" and payment is never mentioned on the call.

​
Test callers enroll like real ones

There is no pre-seeded caller. Every number starts unknown: identify returns known: false, and the first Checkout Session for that number comes back with an empty cards. Enroll the way a real caller does: the agent texts a pay link, you open it and pay with the test card above. From then on that number is recognized, identify returns known: true, and every session offers the saved Visa ending 1111, ready to charge straight away.

​
Apple Pay and Google Pay in test mode

Wallet payments work end to end in test mode. The buttons render on test pay links just as they do live: the sheet opens, you approve with a real card from your wallet, the contact details come off the sheet, and the payment completes. Your card is never charged; the test environment accepts the wallet’s token without moving money, and the payment appears in the merchant’s own processor dashboard like any other test payment.
Wallet payments require a merchant connected through the hosted connect flow (the merchant authorizes Ringup in their processor account). A merchant connected by a pasted access token can take card payments but not wallet payments: the wallet’s one-time token is scoped in a way only an authorized connection can charge.

​
Run a test payment

The general shape is the same on every platform:
1

Reach test mode

Point your agent or bridge at a test merchant you created and start a call, or create a Checkout Session with your rk_test_ key (minted in the dashboard under API Keys).
2

Pay once by link, then by saved card

On your first call the number is unknown: follow the texted link and enter the test card above. Call again and you are recognized: confirm the saved Visa ending 1111 on the call.
3

Read the result

A successful test charge returns status: "succeeded" with a charge_id, and the order_id the wrap-up step reads back to the caller. Your server receives a checkout.succeeded webhook.
Every integration page has a Test it section with the platform’s specifics: which field points at test mode, and what to expect on the call. On some platforms the Ringup dashboard wires this up for you, binding a rehearsal number to a test copy of your agent.

​
Reading test results

The charge response is ground truth, not the assistant’s words. Only a succeeded charge result with a charge_id proves a payment happened. An agent can narrate success it did not have; the API result cannot. Text-chat smoke tests cannot prove voice. Platform chat pipelines assemble handoffs differently from voice pipelines. Validate with a voice call.

​
Edge cases and gotchas

The decline card (4000 0000 0000 0002) returns 402, carrying decline_code, advice_code and the sentence your agent can speak. Your ordinary if (!response.ok) check catches it. See Errors.
A call placed from a dashboard or web widget carries no real caller number, so recognition resolves to nothing. Pin a caller number explicitly (for example +14155550142); once that number has paid once through a texted link, it exercises the recognized path. Real inbound phone calls resolve the caller natively.
4111 1111 1111 1111 never reaches a live payment processor, and a live key rejects it. Use a real card only under an rk_live_ key.

​
Next steps

Pick your integration

Each platform page ends its setup with a Test it section using these fixtures.

Webhooks

Watch the test-mode checkout.succeeded arrive at your endpoint.