Going live

To help you integrate and test your project, use the sandbox and live environments before release.

This document outlines the best practices to ensure that you are fully testing payments in both environments to avoid surprises and unexpected behaviours once the app is deployed to your consumers.

Activate your account

Before you activate your account, ensure that you have tested your app in the sandbox environment and confident that everything is working as expected.

To process live payments, you’ll need to activate your account so that you can access live API tokens and secrets for your apps. This is a quick and easy process:

  1. Login to your dashboard.
  2. Select ‘Activate account’ and complete the registration form.
  3. Select your pricing package and click ‘Submit’.
  4. Your Live token and secret can now be found in the dashboard by opening the ‘Your apps’ tab, selecting your added application, and clicking ‘Live token’.

Once this process is done, we will receive your request to go live and will perform the necessary changes in your account to start processing live payments. We will contact you within one working day once you are ready to go.

Note: Please consider to reviewing the ‘Going live’ section for each different platform you are integrating with in order not to miss any steps of the going live process. Visit as well our Live environment section on this documentation to know all the best practices to successfully test your app in live environment and avoid any unexpected behaviours before you deploy your app to your customers.

Live testing

After you have activated your account, we recommend to test in the live environment performing all the scenarios you completed in sandbox before you release to ensure everything is working as expected.

Use real cards for live testing

You can’t use test cards in the live environment. When testing in live, use real credit/debit cards, by processing small amounts (minimum £1.01 to avoid unexpected declines).

Common test scenarios

Test your project with all the payment types  required, i.e. Register a card and Repeat card payments.

Successful payments
Use the card details provided in the dashboard for generating a successful transaction. Make sure to capture and record the ‘receipt ID’ for this transaction.

If you intend to support repeat payments (one-click payments for example), you should capture the ‘card token’, ‘consumer token’ and the ‘consumer reference’. All three fields need to be provided in a repeat payment for it to be successful.

Note: Please ensure all transactions reaches your back-office.

Declined payments
This test scenario is for generating a declined payment status and applies to Card payments, Pre-authorizations  and Repeat card payments. When testing for a ‘Payment declined’ result, you should process transactions with the following variables:

  • Incorrect CV2 (card security code) values
  • Incorrect/Invalid dates
  • Invalid card numbers
  • Incorrect repeat payments, use an incorrect match of card token and consumer reference

Note: When testing declined payments in live, there are multiple reasons why a payment may be declined. The majority of declines are caused by the processing systems (including fraud prevention) at the card holder’s issuing bank. If you are experiencing unexpected results on your live tests, contact us and we will provide as much information as we can access from the limited information supplied by the issuing bank.

Payment errors
In case of an unexpected error occurring during a payment, i.e. if there is an upstream error processing a transaction, you need to ensure this is handled by your app/backend (depending on your integration).

One example of a test you can perform is to pass an invalid token and secret to see how your app handles the error.

Test security features

To protect your business and your customers against fraudulent transactions, test the security features included in your project.

Address Verification Service (AVS) (if used)
To check AVS, use the test card details provided on the dashboard. We recommend performing tests generating successful and declined payments:

  • Using the correct billing Postcode/Zip code
  • Using the incorrect billing Postcode/Zip code

3D Secure
If you want to test 3D Secure in the sandbox environment, please contact us and we will provide you with test card details to allow you to test if the 3D Secure web page is displayed in your app at the time of transaction. The sandbox environment displays a 3D Secure simulator page that allows you to simulate a success or decline 3DS result. You should check how your app responds to the different results.

Device DNA™
Ensure you have taken all the necessary steps to prevent fraudulent payments. Check that you have integrated all the fields in the API reference section. This applies to mobile and server integrations. For more information please see Device DNA™.

Web payments

If you are using web payments, we recommend to test:

  • Successful result
    Ensure that the payment process redirects the consumer to the ‘Success URL’ (set in the dashboard).
  • Declined result
    Ensure that the payment process redirects the consumer to the ‘Failure URL’ (set in the dashboard).
  • Cancelled transaction
    In the Web payments UI, the customer has the option to click ‘Cancel’. In this case we recommend that you return the customer to the URL they visited before the Web payment was initiated.