From experience, the following testing cases should be performed to address different payment scenarios.
The Blackline eConduit platform removes integrators from PCI PA-DSS scope and EMV certifications, it is not required although recommended to ensure a smooth experience for all clients.
Best Practices
| Item | Recommendation | Reference in documentation |
|---|---|---|
|
Payment Window |
It is important that you do not allow users to close the payment window. If a transaction needs to be cancelled, it must be initiated on the terminal itself. If a transaction is sent and the payment window is closed, the transaction is still showing on the terminal and a customer will typically complete it. Depending on the implementation, this can cause the result to be lost in the POS. Typically a cashier will then run a second transaction which is now a duplicate payment. |
|
|
ResellerName |
Prior to going live, ensure your ResellerName is provided to eConduit and added to the boarding request |
|
|
Partial Authorizations |
Although an amount can be submitted for payment, an approval less than the actual amount can be approved. Ensure your integration can accept approval for the full amount of less than the full amount requiring a second payment command |
|
|
Single device and multiple cash registers |
When pairing devices to cash registers, it is recommended to pair one cash register to one device. Pairing multiple registers to a single device is allowed although it is recommended a second command is held until the device is free. Creating a backlog of commands to the device can create confusion. |
|
|
Client Boarding/Pairing |
Pairing the device to your POS should be automated (not manual) Also, the client information should be passed during the boarding process, not hard coded fields – it improves support by being able to pull up records by business name |
|
|
Transaction Error – Reference ID |
If loss of connection, the use of CheckStatus should be used. CheckStatus will initiate a search in the device for the results. It is recommended that the same transaction and amount is not allowed a 2nd time prior to initiating a CheckStatus. |
You should keep calling the checkStatus until the resultFinal field is true. Please see the checkStatus area in red. |
|
UnpairTerminal |
If the need to unPairTerminals is common for support purposes, consider implementing the unPairTerminal command, it will allow you to remove pairing of devices to registers |
Testing Recommendations
The following are recommended test cases to complete before going live.
| Command | Type |
|---|---|
|
Sale |
swiped |
|
Sale |
Keyed |
|
Sale |
NFC (Apple Pay) |
|
Sale |
EMV (EMV gift cards needed) |
|
Refund |
Swiped |
|
Refund |
Keyed |
|
Refund |
NFC |
|
Refund |
EMV |
|
Cancellation |
Cancellation of transaction at credit card terminal |
|
Void |
Void a transaction still in the device |
|
Tip Adjustment (restaurant application required) |
Ability to adjust tips after the sale |
|
GetSwipe (optional) |
Command to allow you to grab non-sensitive data from the device |
|
CheckStatus |
Perform a checkStatus command to obtain the results of a previous transaction |
Receipt Formatting Recommendations
The following are receipt formatting recommendations for standard payments and EMV payments.
Magnetic Stripe Recommendations
- Payment type (card brand)
- Last four digits of card
- Transaction type (sale, refund, etc.)
- Remove expiration date or truncate
- Entry mode (keyed, swiped)
- Approval code
- Transaction amount
- Card issues agreement language
- Refund policy near signature line
- Signature line
- Cardholder name as it appears in track data (requirement for Discover)
EMV Receipt Recommendations
- Transaction type (sale, refund, etc.)
- Last four digits of the card
- Application Preferred Name or Application Label
- Application Identifier (AID)
- Application Cryptogram type (ARQC or TC)
- Application Cryptogram
- Terminal Verification Result (TVR) if available
- Transaction Status Information (TSI) if available
- Application Transaction Counter (ATC) if available
- Authorization Response Code (ARC) if available
- Approval Code
- Transaction amount
- Card issuer agreement language, if applicable
- Refund policy near signature line, if applicable
- Card Verification method (signature line, pin verified, or no signature required)
- Cardholder name as it appears in track data
