This guide details how merchants can test the client side of their implementations (i.e., what Retail users see when using our payment products) for our payment products in the Sandbox environment, using our test cards.
Currently this page covers the Revolut Pay flow, with further test flows to be added in the future.
Revolut Pay involves a more complex testing scenario due to its connection with our account-to-account (A2A) payment system. This section explains the process and details of the mock sign-up feature, which simulates a new Revolut Retail account creation in the checkout flow of Revolut Pay. This is required for testing A2A payment flows.
The UX in the Sandbox environment is different from the production flow. There is no Sandbox version of the Revolut retail app, which means that certain interactions are simulated differently. Ensure you account for these differences when testing.
This guide will use our Payment links implementation, but will work with every Revolut Pay integration.
Initiate a payment via Revolut Pay on your checkout page.
Select Checkout as a guest
.
Enter the details of one of our test cards for successful payments (with any CVV and future expiry date).
Provide any random user details (first name, last name, email).
Enable saving card information and click Save card and pay ...
.
In the pop-up, provide a random phone number that hasn't been used in the Sandbox before, then click Send verification code
. Save this phone number for testing the account-to-account (A2A) payment flow.
If you enter a phone number that's already registered with a mock retail account, you can either use it for testing the account-to-account flow or try again with a new number to simulate the mock sign-up process.
Click Fill with ... in the top-right corner to autofill the mock OTP (one-time password).
Upon successful payment, you are redirected to the confirmation page.
Your mock account is created with the credentials provided once your initial payment is successful. To test account-to-account (A2A) transactions using the same simulated credentials, follow these steps:
Initiate a new payment via Revolut Pay on your checkout page.
The mock account should be logged in by default. If not, complete the sign-in steps:
Continue
.124455
.On the payment verification screen, confirm that the Revolut account is selected by default in the Pay with section.
Click Pay ...
to proceed.
If additional verification is needed, click Approve in the top-right corner to pass the verification.
In production, customers complete the challenge through the Revolut retail app (if installed) or via a webview. In the Sandbox environment, this step is simulated by the Approve/Decline buttons on the verification screen.
Following these steps will complete the A2A payment flow, allowing you to fully test the account-to-account transaction process using your previously created mock account.
When creating an order to test A2A payment error handling, use the following specific order amounts (in GBP). Pass the exact amount when you create the order so that the Sandbox environment simulates the corresponding error scenario.
Order amount | Case | Decline reason | Payment state |
---|---|---|---|
10.01 GBP | Payment declined without a reason. | No decline_reason returned on payment details | declined |
10.02 GBP | Payment declined due to insufficient funds. | insufficient_funds | declined |
10.03 GBP | Payment declined due to suspected fraud. | suspected_fraud | declined |
10.04 GBP | Payment declined due to exceeded withdrawal limit. | withdrawal_limit_exceeded | declined |
10.05 GBP | Payment declined due to Do Not Honour. This error happens when your customer's bank declines the transaction due to internal reasons. For example, their fraud rules might have been triggered, or a temporary hold may have been applied to this card. | do_not_honour | declined |
You can verify the returned payment.state
and decline_reason
by retrieving the order details.
When testing A2A payment errors using our plugins, ensure you've created products (or set product prices) that exactly match the order amounts listed in this section. This allows the plugin to send the correct amount to trigger each error scenario.