Guides • Accept Payments
Test payment flows
doc

Test payment flows

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.

note

Currently this page covers the Revolut Pay flow, with further test flows to be added in the future.

Revolut Pay

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.

note

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.

  • Mock sign-up feature:
    As the Revolut Retail app is not available in Sandbox, a simulated sign-up process needs to be completed. Once the mock account is created, you can use it to test account-to-account transactions and store our test cards for future use.
  • Revolut Pay A2A in Sandbox:
    The flow includes an initial card payment that triggers the mock sign-up, creating a new, simulated Revolut Retail account necessary for subsequent A2A transactions.

Mock sign-up flow

note

This guide will use our Payment links implementation, but will work with every Revolut Pay integration.

  1. Initiate a payment via Revolut Pay on your checkout page.

  2. Select Checkout as a guest.

  3. Enter the details of one of our test cards for successful payments (with any CVV and future expiry date).

  4. Provide any random user details (first name, last name, email).

  5. Enable saving card information and click Save card and pay ....

  6. 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.

    note

    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.

  7. Click Fill with ... in the top-right corner to autofill the mock OTP (one-time password).

  8. Upon successful payment, you are redirected to the confirmation page.

Account-to-account payment flow

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:

  1. Initiate a new payment via Revolut Pay on your checkout page.

    note

    The mock account should be logged in by default. If not, complete the sign-in steps:

    1. Enter the phone number used during the mock sign-up and click Continue.
    2. When prompted, enter passcode: 124455.
    3. Click Autofill code ... in the top-right corner to pass the OTP challenge.
  2. On the payment verification screen, confirm that the Revolut account is selected by default in the Pay with section.

    • (Optional) If you need to change the payment method, you can select a different option in the Pay with section.
  3. Click Pay ... to proceed.

  4. If additional verification is needed, click Approve in the top-right corner to pass the verification.

    note

    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.

Test for A2A error cases

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 amountCaseDecline reasonPayment state
10.01 GBPPayment declined without a reason.No decline_reason returned on payment detailsdeclined
10.02 GBPPayment declined due to insufficient funds.insufficient_fundsdeclined
10.03 GBPPayment declined due to suspected fraud.suspected_frauddeclined
10.04 GBPPayment declined due to exceeded withdrawal limit.withdrawal_limit_exceededdeclined
10.05 GBPPayment 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_honourdeclined

You can verify the returned payment.state and decline_reason by retrieving the order details.

tip

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.

Was this page helpful?