Testing Guide

This page describes the best practice methods to test your integration with the Worldnet payment gateway using our test server accounts and sandbox accounts. It is intended to facilitate thorough testing, resulting in an issue free launch with our live service. You should have chosen your integration method and be familiar with our Integration Guide and have begun integration before reviewing this document.

Test environment

All testing should always be done on a test environment, separate from the live web server. Testing on the live server can cause many live 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

Setting up the test environment

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
  5. The identical shopping cart version & configuration to the live environment (if using shopping cart software)

Planning your testing

If you are not using a plug-in supplied by Worldnet, then before testing should be attempted at all, you should become familiar with the relevant sections of our Integration Guide document. This is a complete and definitive guide to integrating your systems with the Worldnet 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 gateway.

Background Validation

Also, if using our Hosted Payment Page solution, you should seriously consider implementing Background validation. What Background Validation does is, in the case where for some reason the transaction is authorised but the response fails to get back to your site (customer closes browser/your site is temporarily unavailable/etc.), our host will intermittently send a server side post to a URL with the order ID & transaction result until it receives an “OK” response. This ensures that your order system accurately reflects the transaction result even in the case where the cardholder redirect fails.

Security concerns when testing

The 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 only ever use test card numbers, such as those listed in this document.

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

Things to test

All cases

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 (Authorisation/Decline/Referral/Failure) (see “Testing resources” 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

Per integration method

Hosted Payment Page/POST Page

  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)

XML gateway

  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

When using shopping cart plug-ins

Testing will be quite specific depending on the shopping cart and plug-in being used. If you have downloaded this guide from within a plug-in zip file as apposed to being sent it directly from Worldnet, please e-mail support@worldnettps.com to confirm that you have the latest version on the plug-in for your solution. Please include the name and version number of the shopping cart software and the name of the plug-in zip file that you downloaded.

You should cover all the relevant test above for your integration method, even though the functionality is obscured by the plug-in you are using. The issues outlined above can still occur. However other shopping cart issues that should be tested are:

  1. Card number/CVV fields can only contain numeric characters (no spaces either)
  2. Order status is updated correctly in shopping cart
  3. Customer e-mails are populated correctly
  4. Customers get the right number of e-mails (our host may also send an e-mail to the customer depending on the plug-in)
  5. Session timeouts do not cause transactions not to be dropped/lost
  6. Transactions over 1,000 and 1,000,000 Euro/Pounds/Dollar etc. are handled correctly

Testing resources


Basic transaction testing can be done through our sandbox accounts. You do not need a dedicated test account for this type of basic proof-of-concept testing.

Test Cards

Test cards that can be used on our host are:

American Express 3400000000000000 Y
Debit MasterCard 5100270000000007 Y
Diners 3600000000000008 N
Discover 6011000000000004 Y
JCB 3528000000000007 Y
Maestro 5000330000000000 Y
MasterCard 5001650000000000 Y
Switch 6301144000000009 N
Visa Credit 4539858876047062 Y
Visa Debit 4000060000000006 Y
Visa Electron 4001020000000009 N

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

Various different responses can be simulated by using different cent amounts for transactions. The cent values and their respective responses are:

Cent Value Response
0.01 Declined
0.02 Referral
0.03 CVV failure (Decline)
Any other Authorised

Meaning that if you enter 5.01, 99.01 or 1754.01 you will get a decline, for example.

Testing verification

For large merchants, Worldnet will be happy to coordinate testing with you, provide/review specialised test scripts, and help with any issues raised. If you would like to avail of this service, please feel free to contact support@worldnettps.com.

Except where otherwise noted, content on this wiki is licensed under the following license: CC Attribution-Share Alike 4.0 International