1. Home
  2. Docs
  3. API
  4. Best Practices, Testing and Receipts

Best Practices, Testing and Receipts

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.
Check Status

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

Was this article helpful to you? Yes No