Testing#

Everything you can exercise before you have production credentials. The test cards below drive the sandbox engine, and the two procedures after them cover the cases no card can produce: a callback that fails to deliver, and a chargeback.

Sandbox moves no money. Your PAYMENT_URL differs between sandbox and production and is issued with your credentials, so there is no address to publish here: see Credentials and environments.

No feature forces a callback to time out, so the delivery schedule is exercised by making your own endpoint fail. Point the callback URL at an endpoint you control, have it delay past your timeout or return a status other than 200, and watch the four attempts arrive.

The callback URL is configured per account, not per request. A callback_url sent as a request parameter on a server-to-server operation such as SALE is ignored.

No test card produces one. Sandbox has no card network behind it, so there is nothing to raise a dispute.

Support can create one by hand instead. Settle a sandbox payment, then ask support to trigger a chargeback against it, naming the payment. They record a CHARGEBACK transaction carrying a reason code and a date, and the platform then sends the CHARGEBACK callback exactly as it would in production.

That makes the callback path testable end to end even though the dispute itself is manufactured. What it does not exercise is the timing, since a real chargeback arrives days or weeks after the payment and this one arrives when support creates it.

Handling a chargeback once it arrives, and the rest of running a live integration, are on Operations. When every item here passes, work through the go-live checklist.

Technical questions go to [email protected].

Use these test values in the sandbox environment. All transactions are processed by the test engine, no real funds are moved. Use any 3-digit CVV.

S2S CARD: Scenario Simulation

All scenarios use card number 4111111111111111. The expiry date determines the outcome:

CREDIT2CARD Test Card