Transactional Testing - forum collation
Reading through the forums I started to collate postings on Credit Card testing. Eventually collating these into a document presented for discussion in-house.
While it certainly needs finishing I'd like to share it here and make a request. If you recognise your posting please let me know. I neglected to note the names, apologies for that.
Using Credit Cards and other Payment Methods
A collation of posts and information from:
Testing of transactional functionality is a key activity for UKQA to provide to many areas of the business. This testing is focused around any areas where the member makes payments for goods and services promoted through the service and portal offerings.
Transactional testing may involve Credit Cards, redemption of points, authorising billing to the Members account or perhaps billing through mobile devices. Irrespective, ensuring that payment details are collected, processed correctly to complete the transaction and then kept secure are all areas of testing that need to be considered.
Credit Cards are a primary method for online transactions and so a considered test approach is vital. To perform this testing you will need to identify the card type, generate an algorithmically correct number, a valid expiry date and possibly a card security code.
Types of Credit Cards
There are a number of credit cards valid in the UK. During testing it’s important to understand which of these your payment systems support, then test them all. Valid card types in the UK are:
* Visa, MasterCard, Amex, Diners Club / Carte Blanche, Discover Prefix and JCB
Each credit card is identified by both a prefix and a specific card number length. The prefix identifies exactly what type of card is being used and can be the first step in front-end validation testing. If the prefix is not for a supported card type then front end validation should catch this, avoiding submission of the data and validation in the middleware or backend. The card number length must be that expected for the card type or validation should immediately fail.
The prefix and card number length form the Number Pattern for the particular card type, Number Patterns for valid UK cards are given in the following table.
Table - Algorithmically Correct Number Patterns
Card Type / Prefix / Number Length / Reserved Test Patterns*
</font><ul type="square">[*]<font size="2" face="Verdana, Arial, Helvetica">Visa / 51 – 55 / 16 / not known</font>[*]<font size="2" face="Verdana, Arial, Helvetica">MasterCard / 4 / 16 / 4444-3333-2222-1111 and 4111-1111-1111-1111</font>[*]<font size="2" face="Verdana, Arial, Helvetica">Amex / 34 or 37 / 15 / not known</font>[*]<font size="2" face="Verdana, Arial, Helvetica">Diners Club-Carte Blanche / 300 – 305 36 or 38 / 14 / not known</font>[*]<font size="2" face="Verdana, Arial, Helvetica">Discover Prefix / 6011 / 16 / not known</font>[*]<font size="2" face="Verdana, Arial, Helvetica">JCB / 3 or 2131 or 1800 / 16 or 15 / not known</font>[/list]<font size="2" face="Verdana, Arial, Helvetica">Reserved Test Patterns
There are ‘valid’ credit card numbers that each system sets aside for testing. For example, MasterCard has the numbers 4444-3333-2222-1111 and 4111-1111-1111-1111 marked as test numbers.
Knowing how to generate algorithmically correct number patterns still leaves the issue of generating the expiry date and security code (if needed). There is a risk that our random generation of these numbers could result in the use of valid card details. Where Reserved Test Patterns are available it is recommended these be used.
There are a number of key considerations when using credit cards. It will be necessary to define the architecture of your transaction systems in order to cover the considerations raised here and break them down into relevant testing.
Your application must successfully validate the card details entered and provide suitable error handling. Depending on your system architecture your application can have access to a live interactive check which will either give a positive on negative response as to whether to accept the card as payment method or not. This often includes access to a 'hot file' which holds a list of stolen, cancelled, fraudulently used cards etc.
Outgoing Batch Processing
The transactions are usually then processed as a Batch where all of the days transactions in your application are then batched into a few files for processing, where each transaction has a suitable transaction type attached to it corresponding to Credit, Debit, Refund etc.
In the UK, these files are processed by an organisation called BACS (Banks Automated Clearing Service), there is generally a box which validates file formats and then sends it to the clearing house, you should check if it is possible to send test rather than production files.
The clearing house then validates the sent batch, processes the files and returns them back with suitable return codes for each transaction.
Incoming Batch Processing
Another batch process at the AOL end then verifies the returned file and applies the necessary updates within the application.
Where transactional elements under test are managed by a partner or where processing of transactions is performed on an individual basis, the following test considerations should be included in test scripts.
</font><ul type="square">[*]<font size="2" face="Verdana, Arial, Helvetica">Valid numbers should be handled correctly by the front end and back end all the way through fulfilment. Might want to trap for these if fulfilment is not desired.</font>[*]<font size="2" face="Verdana, Arial, Helvetica">Algorithmically correct but invalid numbers should pass through the front end and be caught by the authorisation functions in middleware or backend.</font>[*]<font size="2" face="Verdana, Arial, Helvetica">Algorithmically incorrect numbers should be caught at the front end.</font>[*]<font size="2" face="Verdana, Arial, Helvetica">Some credit card submission functions include error message cut outs, for example if the card is algorithmically correct but is rejected during authorisation, the system may send an email to the client... don't forget to test those procedural communications.</font>[*]<font size="2" face="Verdana, Arial, Helvetica">Verify the form handling with respect to the formatting of credit card numbers ("nnnnnn" and "nn nn nn" and nn-nn-nn" are all reasonable expectations for formatting [numbers abbreviated for space]). Your interface requirements may vary, but users will use these formats regardless.</font>[*]<font size="2" face="Verdana, Arial, Helvetica">Check for trailing and leading spaces... any QAr worth their salt could tell you stories about those failures.</font>[/list]<font size="2" face="Verdana, Arial, Helvetica">
The document is at:
Please let me know if your name needs to be referenced! [img]images/icons/smile.gif[/img]
[ 06-01-2004, 04:23 PM: Message edited by: UKQATest ]
the rest are all in the Chat or General (where things do not count) - Admin #1. Mods are cute <img border=0 title= alt=[Smile] src=smile.gif /]