Skip to main content

Processor Testing - Knowledgebase / LEGACY Products / Miscellaneous - Cavallo Technical Support

Processor Testing

Authors list
Important Notice

After October 29, 2019, SalesPad will no longer be supporting CardControl. Additionally, the application will cease to be a PA-DSS validated solution as of this date, and therefore CardControl customers would no longer be PCI compliant.

Instead, SalesPad Desktop now offers built-in credit card processing via Nodus PayFabric. If you have questions or want more information on our credit card processing services, please contact your sales rep.


Overview

This document covers some of the automated testing SalesPad performs and processor provided test cases that will allow users to verify that CardControl 3.0 handles successful and failed transactions gracefully.

Automated Testing

SalesPad runs on a regular basis (at least weekly and whenever there are changes to processor code) a suite of automated tests that verify the correct integration with each of the processors we support in CardControl 3.0. This suite consists of seven basic tests that run credit card transactions under different situations. Each of these seven tests run five transactions that have large amounts of data variance.

The seven tests are as follows:

  1. Process 5 Charges (5 Transactions)
  2. Process 5 Authorizations (5 Transactions)
  3. Process 5 Credits (5 Transactions)
  4. Process 5 Authorizations then Capture those Authorization (10 Transactions)
  5. Process 5 Authorizations then Void those Authorization (10 Transactions)
  6. Process 5 Charges then Void those Charges (10 Transactions)
  7. Process 5 Credits then Void those Credits (10 Transactions) The Card Types supported and test numbers include:
  • Amex

o 378282246310005

  • Visa

o 4012888888881881

  • MasterCard

o 5105105105105100

  • Discover

o 6011000990139424

The test suite runs in stages and tests different functionality. Each processor runs each of the stages resulting in a minimum of 1980 total transactions being run.

Stage 1: The processor with using the card data (660 Transactions)

  • Sub-Stage 1.1: Default settings (220 Transactions)
  • Sub-Stage 1.2: With Line Item Data (220 Transactions)
  • Sub-Stage 1.3: Without Line Item Data (220 Transactions)

Stage 2: The processor using Tokenization (660 Transactions)

  • Sub-Stage 2.1: Default settings (220 Transactions)
  • Sub-Stage 2.2: With Line Item Data (220 Transactions)
  • Sub-Stage 2.3: Without Line Item Data (220 Transactions)

Stage 3: Future tests, the processor using Card Present (660 Transactions)

  • Sub-Stage 3.1: Default settings (220 Transactions)
  • Sub-Stage 3.2: With Line Item Data (220 Transactions)
  • Sub-Stage 3.3: Without Line Item Data (220 Transactions)

Stage 4: Future Tests, Processor specific tests. Test cases provided by the processor and tests used to verify bugs do not reappear.

The test suite is extremely flexible and as new test cases are needed they can be added. Adding a new test will add the test to all existing sub-stages. Sub-stages can be added to test different combinations of settings to verify the result of their combination.

This test suite is continually being improved and extended. If a customer has a specific test case they would like added a request can be sent to [email protected]. In the future we hope to provide a utility application that will allow the user to run each of these test cases against their processor to verify their setup.

Manual Testing
Setup

Processors should be in test mode on either the CardControl side or the processor side (or both). This tells the processor that the transaction should not be processed as a live transaction.

Payflow Pro

Payflow Pro provides a method for retrieving a specific response for a transaction. Chapter 5 of the developer documentation explains the specific criteria needed for each test. Some information from the documentation

Testing Guidelines

  • Use only the test credit cards from the documentation, other numbers may create error codes.
  • The card expiration date should be a valid date in the future (i.e. 01/2021)
  • You can use the amount of the transaction to generate a particular result value. The table below lists the general guidelines for specifying amounts to submit in requests.

The table below lists the general guidelines for specifying amounts to submit in requests. From table 5.2 in the documentation

$0 – $1000
RESULT value 0 (Approved)
$1001 – $2000
Certain amounts in this range will return specific PayPal results, and can be generated by adding $1000 to that RESULT value. For example, for RESULT value 13 (Referral), submit the amount 1013.
If the amount is in this range but does not correspond to a PayPal result supported by this testing mechanism, RESULT value 12 (Declined) is returned
$2001+
RESULT value 12 (Declined)

The full documentation can be found here https://www.paypalobjects.com/webstatic/en_US/developer/docs/pdf/pp_payflowpro_guide.pdf

AssureBuy & BluePay

AssureBuy & BluePay support sending the error code that you would like to receive with the transaction you are sending. This functionality is implemented similar to the other processors but requires that a setting be enabled to turn the functionality on.

Settings

Send Amount as Response – Enables test mode as described in the AssureBuy documentation (Only Functions if the Processor is in “T” Mode).

To receive a specific response enable the above setting and send the response code you would like to receive as a whole dollar amount. Ex to receive error code 5211 – Missing or invalid currency code, send the amount of

$5211.00 as your transaction amount

Important

When testing BluePay with the setting ‘Send Amount as Response’ set to false, any transaction with an even dollar amount will receive the response “Transaction Failed: Denied.” Odd amounts are treated as a normal test transaction. Please note this is a policy put in place by BluePay, not CardControl.

The full documentation and list of error codes can be found here https://www.bluepay.com/support/

Litle Online

Litle Online provides a comprehensive list testing all functionality of the processor. Specifying the data from the documentation will verify the functionality of the CardControl integration. Chapter 2 provides test cases.

3 Delta

3Delta does not currently have documentation dedicated to testing. Explanations for all transaction status and error codes can be found here: https://3dsi.zendesk.com/hc/en-us As with every processor, it is recommended that all types of transactions are tested with the desired CardControl configuration.

FirstDataE4

FirstDataE4, like 3Delta, has no dedicated testing documentation and uses basic testing functionality. The available response codes can be found here.

Moneris

Moneris supports the following test cards:

o MasterCard - 5454545454545454

o Visa - 4242424242424242 or 4005554444444403

o Amex - 373599005095005

Helpful Unhelpful