SDK Integration accreditation rules

Overview

During the validation stage of your technical integration journey with Handpoint, Handpoint verifies how the integration is done with the Handpoint SDK, and ensures that it supports all the  functionality that is required for the accredited solution. When an accreditation is done with a processor bank, a couple of rules need to be enforced by the Point-of-Sale application so that the solution honours the card processing requirements put forward by the acquirer and the card schemes. Below you find some of such rules and support requirements so that you can implement in your solution.

Note that the receipt images in this document are examples from one acquirer. The receipt layout can be different between acquirers, but these example should correctly demonstrate the difference between each rule.

Accreditation Rules

Rule 1:

The card transaction must produce card transaction receipts that can be given to the cardholder as a confirmation that the card transaction has been performed correctly.    

If a card has been used, then a receipt will be provided whether the card transaction results in either success or error.

The Handpoint SDK library produces all card transaction receipts which have been accredited with the acquirer so the POS application does not have to be involved in creating the card transaction receipts. The task that the POS application is required to do is to print out the receipts to give to cardholder and for storage by the merchant. Each time a card transaction is performed then at least two receipts are generated by the Handpoint SDK. Those receipts then need to be printed out (or delivered via email). They are made available in the transaction result data structure that Handpoint SDK returns to the POS application.

Examples of merchant and customer receipts supplied from the Handpoint SDK:

      

Rule 2:

The solution must support cardholder verification processes such as PIN and cardholder signature. 

The Handpoint SDK supports card verification methods such as cardholder PIN and cardholder signature. Cardholder PIN is prompted on the card reader and is securely processed on the card reader but cardholder signature needs to be received by printing out a signature receipt that the cardholder needs to sign or via a touchscreen. The POS application receives a notification from the Handpoint SDK that a cardholder signature is required by that card.  Along with the cardholder signature notification there is a merchant receipt including a signature line. The cardholder needs to sign their name on the line for the operator of the POS solution to verify against the signature on the cardholder's card. If the signatures match then the operator on the POS application can let the system know that the signature match to finalize the card transaction. If the signature is approved a cardholder receipt is returned in the transaction result. If the signature does not match, the transaction is aborted and both merchant and cardholder receipts are returned and printed in the transaction result.

Proposed procedure of prompting for signature match:

  1. Transaction is started on the card reader
  2. Card is inserted for reading
  3. Card requires cardholder signature for cardholder verification
  4. Handpoint SDK notifies POS application to prompt for signature verification and to print out signature receipt
  5. POS application prints out the signature receipt and prompts the operator if the signature matches on the receipt and cardholder's card
  6. The POS application prompt has two options: Approved or Declined. If the signatures match then Approved is pressed and the transaction is authorised. If signatures dont match Declined is pressed and the transaction is voided. The Handpoint SDK has functions and return values that enforce this behavior


Examples of merchant and cardholder receipts supplied by Handpoint SDK with cardholder signature verification:

  

Rule 3:

It must be possible to make a correction to an authorized card transaction.  

When processing a card transaction, either sale or refund, there must be a way of reverting or correcting the transaction if there is some mistake done when it is initiated. Example if an incorrect amount is entered and charged to customer card.

The Handpoint SDK offers couple of ways to make corrections to an authorised card transaction. For a sale card transaction it is possible to either void (revert) it or to make a refund or sale all depending on what the transaction type is.

To correct a sale transaction:

  1. Use void sale function from the Handpoint SDK to revert the transaction. Note that it is only possible to void transactions within the same day because if the sale transaction has been settled against the acquirer, it is out of scope for voiding. If sale transaction is successfully voided then it does not show up on customers card statement.
  2. Use refund function from the Handpoint SDK with the same amount as the previous refund transaction. Refund on customers card can be done at any time but it will affect the customers card statement and the customers card balance will be incorrect until the refund is settled at end of day.

To correct a refund transaction:

  1. Use the void refund function from the Handpoint SDK to revert the transaction. Note that it is only possible to void transactions within the same day because if the refund transaction has been settled against the acquirer it is out of scope for voiding. If refund transaction is successfully voided then it does not show up on customers card statement.
  2. Use the sale function from the Handpoint SDK with the same amount as the previous refund transaction. Sale on customers card can be done at any time but it will affect the customers card statement and the customers card balance will be incorrect until the refund is settled at end of day.

Examples of receipts for a transaction that has been voided.
  


An additional way of correcting a transaction can be used, for example if there is a way of doing refunds or voids on the card transaction from other system that the merchant is using.


Rule 4:

There must be a way of recreating the card transaction receipts, both merchant and cardholder receipts.

If there is an issue with printing the receipts in the POS application(for example, if the printer runs out of paper), the receipt is corrupted, or cardholder accidentally loses the receipt, there has to be a way of reprinting the receipt. If a receipt is reprinted then the copy must clearly be a reprint of the original. The copy receipt indicator must be placed in the middle of the receipt so that it can't be torn off or otherwise removed. This is required due to reasons of charge-back, e.g. the card holder could possibly show up with many receipts stating that he has bought something that he should be able to have refunded.

For Datecs (Hilite/HiPro) devices only : 

The Handpoint SDK offers a placeholder within the receipt source string that it delivers to the POS application. With that the POS application can store the receipt source, and if it needs to reprint, it replaces the placeholder with a copy receipt marker such as '********* COPY RECEIPT **********' or similar. The placeholder is put in the middle of the generated receipt created by the Handpoint SDK.  In the case when an original receipt is being printed then this place holder should be removed during printing.

Place holder = {COPY_RECEIPT}


Examples of original receipt that is being reprinted:

  


Support requirements

Other functionality within the Handpoint SDK can be implemented for support reasons if the card payment solution on the card reader needs to be serviced in some way.    

Logging

In some instances, logs need to be retrieved from the card reader and the Handpoint SDK library. The card reader creates audit log for each transaction that may be required by Handpoint support to see how card transactions are being processed on the card reader. The audit log on the card reader is deleted before each new transaction is started so it is recommended to fetch the log from the card reader after each card transaction or process that the card reader performs. Log levels can also be set if extensive logging is required

Software and configuration update

The card reader configuration and software will require some maintenance so it is recommended to include a software and config update function. This is available in the Handpoint SDK  and is supported in the POS application or any other software using the Handpoint SDK. By including the update function from the Handpoint SDK, the card reader is forced to check for any pending card reader updates on the Handpoint maintenance servers. If the update function is enabled, the card reader connects to the Handpoint maintenance server, downloads any update that might be pending, installs it, and is ready for usage again. A notification from the Handpoint support team should be issued when an update is available so this update function does not necessarily have to be used each day.

Copyright 2018 Handpoint