Non-unique approval numbers for forwarded payments

[#1]

We are adding store-and-forward to our triPOS payment integration.

We always use store=automatic and forward=automatic.

Currently, we are developing against triPOS 5.14 on a Windows 10 machine.

We can now successfully cause payments (triPOS sale) to be stored by unplugging the network cable.

In our latest test, there were three stored payment transactions in the triPOS database.

When we plugged the network cable in, the stored transactions were forwarded.

When we reviewed the stored transactions that were "Processed", these three all had an approval number 000043.

Should we expect payments (and refunds?) to have non-unique approval numbers?

We have attached the XML response from the triPOS stored transactions API endpoint where you can see the three storeTransaction elements containing the embedded json blob that carries the approval number.

Many thanks,

Mark Shipman

[Alumni · Accepted solution]

Mark,

In this particular case, the duplicate approval numbers were caused by behavior on our test simulator.

In production processing, approval codes are usually but not always unique.  Some card issuers will return duplicate approval codes for separate transactions.  Store and Forward could actually increase the likelihood of duplication, because the transactions will process in rapid succession once connection is re-established.  Some issuers appear to generate approval codes based on a timestamp.

You can lean on our TransactionID to help differentiate between transactions in case of duplicate approval codes.  Rest assured that we, and the issuer, are tracking each transaction separately, and there will be no negative impact from settling the transactions as normal.

- Kevin Martin
Developer Integrations, Vantiv Integrated Payments