Skip to main content
Payment simulators are provided for card, PayPal, and SPEI payments, allowing you to test card payments, redirect payments, and push payments respectively. These simulators do not connect to any PSP and instead provide mocked responses based on the amounts or other values passed in.

Setup

To set up a simulator, head over to your sandbox dashboard and go to the connections catalog. Once there, each simulator is available to set up with a custom merchant ID. This ID does not serve any purpose. Please note that simulators are not available in production environments.

Test values

Payments

When creating a payment, the following test values can be used to simulate various error codes. The following amounts can be used to test pending outcomes:

3-D Secure

The card simulator supports PSP-hosted 3-D Secure, where the payment service performs the authentication as part of the transaction. To simulate an authentication outcome, include a metadata value in the request with "require_three_d_secure": "true" and prefix the simulator amount with one of the following values: Prefixes 90 to 93 return a buyer_approval_pending transaction with a redirect URL, and the authentication outcome is applied when the buyer returns from it. Prefixes 94 and 95 complete the authentication as part of the create request, so the 3-D Secure data is returned in the initial response without a redirect. You can combine one of these prefixes with another simulator amount to control both the authentication outcome and the payment result. For example, an amount of 90200001 returns the challenge success data together with a canceled_payment_method error code.

Captures

When capturing an authorized payment, the following responses can be simulated. When capturing a payment, the following test values can be used to simulate various error codes. Additionally, the 408 amount can be used to simulate a connector request that times out. An asynchronous retry is scheduled if idempotent retries are supported.
Transactions in a capture_pending state can be moved to the next state using webhooks.

Void

When voiding an authorized payment, the following responses can be simulated. When creating a payment, the following test values can be used to simulate various error codes.
Transactions in a authorization_void_pending state can be moved to the next state using webhooks.

Refunds

When refunding a card payment, the following responses can be simulated. When creating a payment, the following test values can be used to simulate various error codes.

Scheme transactions

When creating a card payment, random scheme_transaction_id and transaction_link_id values are generated. An amount of 10001 can be used to simulate a missing scheme_transaction_id and transaction_link_id.