Testing Guide

This page describes how to test your integration prior to certification. It is intended to facilitate thorough testing, resulting in an issue free go-live. Prior to reviewing this section, it is recommended that you first choose your integration method(s) and familiarize yourself with the API Specification.

All testing should always be done using test accounts on the test environment. Testing with live accounts on the live payment gateway can cause problems such as:

1. Unnecessary downtime
2. Live transaction corruption/loss
3. Incorrect/incomplete results of live transactions
4. Customer frustration
5. Undiscovered issues over time, effecting large numbers of transactions
6. Chargebacks
7. PCI DSS implications

You should ensure that your test environment is configured as close as possible to your live environment, particularly:

1. Web server (IIS/Apache) version
2. Web server configuration, especially the language interface (PHP/ASP etc.) and session timeout
3. Database connectivity
4. Firewall

Before testing, you should become familiar with the relevant sections of our API Specification. This is a complete and definitive guide to integrating your systems with the gateway no matter what programming language, transaction types or integration method.

Planning your testing depends a lot on your method of implementation. For example if using our Hosted Payment Page (HPP) you should test the situation where a redirect back from our host fails, whereas this is unnecessary if you are using the XML method.

If you are using the Hosted Payment Page method of integration, Background validation must be supported by your application flow. For more information on background validation, please consult the background validation documentation page.

PCI DSS states that you should never use live cards in a test environment, otherwise this environment is also subject to PCI audit and DSS rules. For this reason you should use only test card numbers, such as those listed in this document.

We cannot be held accountable for live cards being put through our test systems and sandbox accounts.

You should ensure that your test environment is configured as close as possible to your live environment, particularly:

1. Host is unavailable (i.e. Use invalid test host URL)
2. Request details (including hash) are incorrect
3. Response Hash string is incorrect
4. Responses for all possible transaction results (Authorization/Decline/Referral/Failure) (see “Sandbox Accounts and Test Cards” section for details)
5. PCI DSS guidelines are met in all scenarios
6. Refreshing the receipt page does not re-perform the transaction/resend the receipts
7. All required currencies are processed correctly

1. Customer doesn't complete transaction (e.g. closes browser window)
2. Incorrect Receipt Page URL configured (same as response redirect failure)
3. Customer takes 60 mins to complete entering details
4. Simultaneous transactions do not interfere with each other
5. Background Validation is successful for all transactions and responses (if implemented)

1. Card number/CVV fields can only contain numeric characters (no spaces either)
2. Non-numeric characters (including spaces) are not sent in numeric fields
3. Remote XSD file unavailable (fallback to local cache?)
4. XML fails validation against remote XSD file
5. Host returns a failure due to incorrect content in XML request
6. Host returns a System Error response
7. Host does not return anything
8. Host returns extra response fields

Testing Verification

Basic transaction testing can be done using the public sandbox accounts. You do not need a full test account for basic proof-of-concept testing. The terminal details are:

• TERMINAL E: MCP is the Multi Currency Terminal Setting.

Test cards that can be used on our host are:

All test cards can be used with any expiry date in the future, and any CVV (American Express cards have a 4 digit CVV).

All test cards can be used with any expiry date in the future, and any CVV (American Express cards have a 4 digit CVV).