Skip to main content

Search

Sign in

Test Plan

  • Updated

The purpose of the following section is to validate the implementation of the Generic POS Channel protocol for the transaction sets chosen by the Integrator.  An Integrator may choose to only implement a subset of all the Test Cases (1, 2, 3, 4 and 5) below but, having chosen a Test Case, all sub Test Cases and the transaction types applicable to these Test Case must be performed.

By way of example, if an Integrator only wants to perform Debits then only Test Case 3 comprising 3.0, 3.1, 3.2, 3.3 and 3.4 need to be tested and logs for these submitted. In this case logs for 3.0a, 3.1a, 3.1b, 3.2a, 3.3a, 3.3b, and 3.4a would need to be submitted.

Integrators should keep logs of all requests sent to the Indigo Server as well as the responses received and the data and time of submission and receipt of these messages. These logs must be submitted to iVeri Support (support@iveri.com) who will create a project within iVeri's Redmine System, validate and attach the logs submitted. Any logs not submitted indicate that the Integrator does not intend to use the transaction types omitted and these will be removed from the Merchants Profile on the iVeri Gateway leaving the Transaction Types for which logs have been received.

Key

Key Expected Result
  Transaction where a response is received and the Result:Code indicates success.
  Transaction where a response is received and the Result: Code indicates Failure.
  Transaction where a response is received but the Result:Code indicates a Timeout.
  Transaction where no response is received. e.g. No card is presented to the Device and the web service call to Indigo times out.

 

1.  Initial Authorisation

Test Case a b Description
1.0 Authorisation   Successful response.
1.1 Authorisation AuthorisationReversal A successful Authorisation is obtained but an exception in the Integrator's system requires that a reversal of that Authorisation must be performed.
1.2 Authorisation   Declined e.g. No Funds in the card. Check that the Integrators system does not consider this to be a successful transaction.
1.3 Authorisation Void Timeout received from Acquiring Host. The Integrator must send a Void to ensure that the transaction is rolled back by Indigo.
1.4 Authorisation   Card not presented to Device. In this case no response at all is received from Indigo.

 

2.  Follow-up Debit

Test Case a b c Description
2.0 Authorisation Debit    Successful response received to both the Authorisation and the Sale thereafter.
2.1 Authorisation Debit Void Successful response received to both the Authorisation and Sale but then an exception in the Integrators system occurs requiring that the Void is executed to ensure no financial implications for the cardholder.
2.2 Authorisation Debit   Success response to the Authorisation but the Sale returns a Failure
2.3 Authorisation Debit Void Successful response to the Authorisation but a timeout occurs when processing the Sale and the Integrator must execute a void to make sure that there are no financial implications to the cardholder.

 

3.  Initial Debit

Test Case a b Description
3.0 Debit   Successful transaction.
3.1 Debit Void Successful Sale but then an exception in the Integrators system occurs and the Integrator must reversal the Debit so that there is no impact on the cardholders account
3.2 Debit   Transaction Declined e.g No funds available. This must not be marked as a successful sale by the Integrator.
3.3 Debit Void Timeout from Acquiring Host. The Integrator must ensure that a Void for this transaction is executed.
3.4 Debit   Card not presented to Device and the web service eventually times out and no transaction is actually even attempted.

 

4.  Follow-up Credit

Test Case a b c Description
4.0 Debit Credit    Success response from a Sale and then the Integrator gives the money back in the Refund. Note the delay that may occur between Sale and Refund.
4.1 Debit Credit Void Success then Success then Rollback due to exception in Integrators systemSuccess. The Void would only apply to the Credit so the merchant would effetively still have the money obtained during the Sale
4.2 Debit Credit   Success then Failure of the Credit. The money must be returned to the customer some other way.
4.3 Debit Credit Void Timeout from Acquiring Host.The Void would only apply to the Credit so the merchant would effetively still have the money obtained during the Sale.

 

5.  Initial Credit

Test Case a b Description
5.0 Credit   Success Payment of money to the cardholder
5.1 Credit Void Exception in the Integrator's system leading to the reversal of the Payment
5.2 Credit   A payment to the cardholder has been Declined.
5.3 Credit Void Timeout from Acquiring Host, this needs to be resolved with the use of a Void to unwind the transaction.
5.4 Credit   Card not presented to Device and the web service times out.

 

In addition to the above there are some general tests that need to be performed to take care of the following situations.

  • Transactions being performed by two devices simultaneously to check that if there are two transactions being performed at exactly the same time that the Integrators systems as well as the Indigo server handles this successfully.
  • Error code 255 indicating a system error. These generally indicate an actual programming error and the details of what has happened must be logged and a notification to someone created (e.g. email) so that the exact cause can be investigated and the programming issue resolved.
  • Void must be executed until either a positive response is received OR 24 attempts have been exhausted OR more that 24 hours has elapsed. It is recommended that an Integrator puts voids onto a queue and then has a separate process which sends the voids to Indigo until one of the above conditions is met.
  • If the Integrator wants to offer cash back as an option then the setting of the “CashAmount” parameter must be tested.
  • If the Integrator wants to offer budget period as an option then the setting of the “BudgetPeriod” parameter must be tested.
  • If the Integrator wants to obtain data input from the POS device then the GetData command must be tested.
  • If the Integrator makes use of the Cancel command to return control to the calling process in the event that a card is not presented to the POS device e.g. Cash is tendered, the this should be tested as well.