1. HCM Info
  2. Heartland Restaurant
  3. Credit Card Processing
  4. Payment Terminals

Duplicate Transactions and Charges for HR

[[ video.video_data.title || (video.article_name + ' - ' + video.video_id) ]]

Duplicate Transactions and Charges for HR

Overview

This document is intended help you understand what leads to duplicate transactions/charges in Heartland Restaurant and provide solutions for resolving them.

What is a Duplicate Transaction/Charge?

A duplicate transactions/charge refers to a card being charged more than once for the same amount. Depending on the situation, one or both charges show in POS reports. The dealer community refers to a group of these type of issues with transactions as ‘duplicate charge issues’.

Note that it’s possible transactions were not funded for in the past or were ‘missing’ as a result of duplicate logic changes.

What causes a Duplicate Transaction/Charge?

The majority of duplicate charges result from the following scenario:

  1. Staff member presses ‘Card’ on a ticket to pay through a PAX device
  2. Staff member follows the prompts on PAX to complete payment
  3. Payment approves
  4. Approval message does not automatically communicate the approval to the POS tablet so the POS remains on the Please Complete Payment screen

When this situation occurs, the cause is the local network connection between the PAX and the POS breaks so the POS never receives the approval message and completes the transaction.

At this point, what happens next depends on the actions the staff member takes and if they are on the recommended configuration.

A duplicate charge may occur if payment is:

  • Reattempted on a different ticket
  • Entered for a different amount
  • Attempted on a different tablet/PAX, or
  • Processed using a different card number

All of the above factors matter so the local duplicate checker can do its job. See the Not Recommended section of this document for a more detailed explanation of how these actions can create duplicate charge issues.

Resolving Duplicate Transactions/Charges

Recommended Environment

  • All PAX devices should be updated to the latest version for Heartland Restaurant
    • Minimum versions: PAX S300 1.01.06E, PAX S920 1.01.02E, PAX A920 1.01.22E
  • All PAX devices must have:
    • Duplicate Check by ECR Reference number - enabled. This setting adds another identifier in for duplicates that is the equivalent of a ticket ID in our system. This helps prevent transactions from being incorrectly flagged as duplicates.
    • Local duplicate checking - enabled
    • Settings are found on ‘industry’ tab in PAXStore/BroadPOS
  • Software version 6.70 or above on all tablets
  • On Admin Portal > Location Setup > Settings > Cancel Running EMV Transactions – enabled
    • This setting allows a ‘cancel’ option to appear after 30 seconds on the Please Complete Payment screen allowing the merchant to exit the page and more quickly reattempt the transaction than if they were to wait for the POS level timeout 2-3 minutes later.

Heartland Processing

  • Location Setup > Payment Gateway > SDK set to Heartland SDK not Legacy SDK
  • Location Setup > Payment Gateway > Portico direct checkbox in In-Store Settings - enabled

Note: Depending on a site’s setup, the Heartland In-Store Settings box must be populated or changed to credentials that match what’s in the site’s PAX devices.

Recommended Procedure

  1. Press ‘Card’ to process the transaction
  2. Follow steps on the PAX device to complete the transaction
    Note: If the staff member or customer change their mind and do not want to process the card, tap the ‘X’ (abort) key on the PAX device itself before approval or decline is received on the PAX device.
  3. PAX approves/declines
  4. If POS does not receive message, wait a few seconds and tap ‘Cancel’ on the POS.
  5. Press ‘Card’ again on the same ticket, using the same credit card, for the same amount, on the same PAX device/tablet
  6. Follow steps on PAX again and wait for PAX messaging
  7. Did the transaction previously approve?
    • If yes, the POS will recognize this and pull in the card information for reporting without recharging the card.
    • If no, the POS will add the transaction to the ticket normally and charge the card or display an error message from PAX.

      At this point, if this action fails to reach the POS again, there’s likely a local network issue that needs to be addressed between the PAX and the POS. Once the issue is resolved, repeat steps 1-5 until the transaction completes.

      If after multiple tries, the transaction still cannot be completed on the original PAX device due to network issues, the merchant should call the credit card processor to confirm if the transaction processed on their end and take appropriate action while the network issue is addressed.
  8. Did the credit card processor confirm the transaction processed successfully?
    • If yes, as a suggestion, the merchant can apply a Custom tender named something like ‘Card Payment Correction’ on the POS ticket to allow POS reports to show a transaction did occur successfully. Note that tips will not be able to be charged in this scenario since only the original payment will have gone through. The merchant would have to continue trying the transaction to capture a tip or process a transaction that is only for the amount of the tip.
    • If no, the merchant can reattempt the transaction on a different station with a working PAX device or tablet.

Not Recommended

There are some actions we do not recommend because they can actually lead to duplicate transactions even on the correct environment. We do not recommend:

  • Force closing the POS application while payment is progress or the POS is on the Please Complete Payment If the ticket was not previously saved, the system discards it. When the POS comes back up, if you attempt to re-ring the transaction, it would be on a new ticket/ECR Ref number bypassing local duplicate checkers.
  • Reattempting payment on a different PAX or tablet after cancelling/force closing. Local duplicate checking is set up on each individual PAX device so it cannot recognize duplicates across multiple devices at once. If you attempt to process on a different device, it bypasses duplicate checkers.
  • Reattempting payment with a different amount or a different card. The PAX and POS will see this as a separate transaction so it will not flag as a duplicate.
  • Discarding the ticket after cancelling payment. If the payment did go through originally, it will remain in the batch and continue not to show in the POS. If the ticket is discarded and an attempt is made to do a new ticket, it bypasses the duplicate checkers.
  • Be on a non-recommended environment. All pieces in the Recommended Environment section of this document work together It’s important that all recommendations are set up.

Duplicate transactions issue in version 6.40 and lower

An issue was reported in version 6.40 and lower when PAX updated their logic in handling duplicates. Our team was not made aware of this change and saw the effects in the form of batch variance escalations. Still unaware of this change, our development team coded to better accommodate the scenarios where duplicates were occurring by adding in an Auto-reversal feature that automatically reversed a transaction if the 'cancel' button was pressed or if the transaction timed out at the POS level while waiting for the PAX (takes 2-3 minutes).

The coding solution we implemented lead to an unexpected scenario where if a transaction successfully auto-reversed and the merchant reattempted on the same card, amount, ticket, etc., as we recommended, it would display as if the card was approved but, be sent as a duplicate transaction. This scenario resulted in the card never being charged and also made tipping to the transaction impossible. In some instances, the auto-reversal feature would occur too quickly, prior to the transaction fully processing from the PAX resulting in the transaction remaining in the batch and never showing up in the POS. When this occurred, support began recommending turning off the 'Cancel' button under Location Setup > Settings which led some merchants to force close the application preventing an auto-reversal from triggering. The merchant got funded for transactions, but the real issue wasn’t resolved.

When merchants pulled the system back up, they could follow the procedure of running the card on the same ticket, amount, card, etc., and would either get a DUP TRANSACTION error (confirming they were funded for the transaction however, the transaction was not added to reporting on the POS end) or the transaction went through and approved normally (indicating the transaction did not process successfully originally).

Our teams were eventually notified of the duplicate logic change in the PAX and created a special testflight version that had additional code to properly handle duplicate transaction scenarios. Additionally, a phased PAX Update plan was created to update all PAX S300 devices in the field to have version 1.01.06E and Duplicate Check by ECR Reference number – enabled and Local duplicate checking - enabled.

The new recommendation was to get any regularly affected site updated PAX devices and installed on the testflight version. This resolved most of the duplicate issues caused by how our software handled flows. With the 6.40 release, all PAX S300s phased updates were completed and 6.40 was released to have the auto-reversal feature removed and correct duplicate handling.