
Integration Testing
Quick Find
Go straight to the section you need.
1.0 Gateway Integration →
2.0 New Transactions →
3.0 Management Requests →
4.0 AVS/CV2 Checking →
5.0 3-D Secure Authentication →
11 Receipts and Notifications →
17 Advanced Data →
17.7 Device Information Fields
19 Gateway Wallet →
26 Digital Wallet Transactions →
Appendix
A-1 Response Codes
A-1.1 Authorisation Response Codes
A-2 AVS / CV2 Check Response Codes
A-3 Secure Authentication Data
A-4 3-D Secure Enrolment/Authentication Only
A-9 Duplicate Transaction Checking
A-10 Capture Delay
A-13 Sample Signature Calculation
A-14 Transaction Life cycle
A-14.1 Authorise, Capture and Settlement
A-15.2 Mail Order/Telephone Order (MOTO)
A-15.3 Continuous Authority (CA)
A-16 Payment Tokenisation
A-16.1 PREAUTH, SALE, REFUND, VERIFY requests
A-16.3 CANCEL or CAPTURE requests
A-16.5 SALE or REFUND Referred Authorisation requests
A-18 PSD2 SCA Compliance
A-18.1 Obtaining Strong Customer Authentication
A-18.3 Exemptions to Strong Customer Authentication
A-19 Hosted Payment Page Options
A-20 Integration Libraries
A-20.1 Gateway Integration Library
A-20.2 Hosted Payment Page Library
A-20.3 Hosted Payment Fields Library
A-21 Example HTTP Requests
A-22 Example Integration Code
A-23 Example Library Code
A-23.1 Gateway Integration Library
A-12 Integration Testing
You will be provided with unique test Merchant Account IDs during the onboarding process. Refer to section 1.6 for more information.
Test Merchant Accounts are not connected to our Simulator and not to an actual Acquirer. The Simulator will emulate the function of an Acquirer and provide simulated responses and authorisation codes.
A-12.1 Test Amounts
When testing the transaction amount can be used to trigger different authorisation and settlement outcomes as follows:
Any other amount will return a responseCode of 66311 (Invalid Test Amount).
The settlement outcome only applies to transactions which reach settlement due to being successfully authorised and captured and not cancelled. The amount captured is used when determining the settlement outcome rather than the amount authorised.
The range 5000 to 9999 can be used to test manual authorisations. If the transaction does not contain an authorisationCode request field, then the Simulator will return a responseCode of 1 (CARD REFERRED). If it does, then it will return a responseCode of 0 (SUCCESS), with an amount between 50000 and 7499 being accepted at settlement and an amount of 7500 to 9999 being rejected.
The range 20000 to 29999 can be used to test SCA soft declines. If the transaction is eligible1 to request SCA then the Simulator will return a responseCode of 65 (SCA REQUIRED). If not, then it will return a responseCode of 0 (SUCCESS) for the range 20000 to 24999 or 5 (DO NOT HONOR) for the range 25000 to 29999. Successful transactions will be approved at settlement.
A-12.2 Test Cards
The test accounts will only accept card numbers that are designated for test purposes. These test cards cannot be used on production accounts.
To test AVS and CV2 verification then the associated CVV and billing addresses are provided for each card. If a different value is used, then the Simulator will mark the responses as ‘not matched’.
Unless stated otherwise an expiry date sometime in the near future should be used.
A-12.2.1 Visa Credit
Card Number
CVV
Address
Card Number
CVV
Address
Card Number
CVV
Address
A-12.2.2 Visa Debit
Card Number
CVV
Address
Card Number
CVV
Address
A-12.2.3 Electron
Card Number
CVV
Address
A-12.2.4 Mastercard Credit
Card Number
CVV
Address
Card Number
CVV
Address
Card Number
CVV
Address
Card Number
CVV
Address
A-12.2.5 Mastercard Debit
Card Number
CVV
Address
A-12.2.6 UK Maestro
Number
CVV
Address
Number
CVV
Address
A-12.2.7 JCB
Card Number
CVV
Address
A-12.2.8 American Express
Card Number
CVV
Address
A-12.2.9 Diners Club
Card Number
CVV
Address 1
Merchant Account is used with AVS is turned off.
A-12.3 3-D Secure Testing
Your test accounts are connected to our 3-D Secure Product Integration Testing (PIT) system rather than to the production 3-D Secure servers.
You can use any of the test cards provided in section A-12.2 with this PIT system and can test various enrolment and authentication scenarios as follows.
A-12.3.10 3-D Secure version 1
For 3-D Secure v1 all the standard test card numbers will show as enrolled except for:
Card Number
Enrolment
Simulation
Card Number
Enrolment
Simulation
Card Number
Enrolment
Simulation
Card Number
Enrolment
Simulation
The desired authentication status (threeDSAuthenticated) can be selected on the challenge dialog shown by the PIT Access Control Server.
A-12.3.11 3-D Secure version 2
For 3-D Secure v2 all the standard test cards will show as enrolled, and the authentication status returned by the Directory Server (for frictionless flow simulation) can be selected using the value of the card expiry month as follows:
Card Expiry Month
Auth Status
Simulation (Frictionless)
Card Expiry Month
Auth Status
Simulation (Frictionless)
Card Expiry Month
Auth Status
Simulation (Frictionless)
Card Expiry Month
Auth Status
Simulation (Frictionless)
Card Expiry Month
Auth Status
Simulation (Frictionless)
Card Expiry Month
Auth Status
Simulation (Frictionless)
Card Expiry Month
Auth Status
Simulation (Frictionless)
Card Expiry Month
Auth Status
Simulation (Frictionless)
Card Expiry Month
Auth Status
Simulation (Frictionless)
Card Expiry Month
Auth Status
Simulation (Frictionless)
Card Expiry Month
Auth Status
Simulation (Frictionless)
Card Expiry Month
Auth Status
Simulation (Frictionless)
An expiry month of 12 will simulate the non frictionless flow and desired authentication status (threeDSAuthenticated) can be selected on the challenge dialog shown by the PIT Access Control Server.
When using an expiry month from the above table please use a suitable expiry year to ensure the date is sometime in the near future.