Transaction retry deduplication refers to the process of removing unsuccessful retry attempts of the exact same transaction made with the exact same payment method from your overall transaction data. Identical retries of this sort occur for various reasons, such as:

• A customer re-attempts the same card multiple times because they don’t understand why it was rejected
• You employ a subscription retry strategy that automatically retries the same vaulted card credentials every X number of days until it succeeds
• As a part of your transaction fallback or routing logic, you always retry failed transactions with each of your individual processors
• You experience a fraud attack from a bot that runs batches of cards repeatedly to check for card balances

How Duplicate Transactions Retries Impact Your Payments Data

When you retry the same transaction over and over—and it fails for the same reason each time—those failures can create noise in your payments data that makes certain metrics appear misleading. For example, if you retried the same Visa card five times before it succeeded, your raw payment metrics would show attempted Visa transactions; without the context of knowing those were all duplicate retries, the data may lead you to believe you processed six separate Visa transactions, five of which failed. On a small scale, this might not seem important, but approaching your entire transaction volume without this context can lead to incorrect assumptions about your customers, their preferred payment methods, and the overall success of different transaction types.

Approval Rate

Removing duplication retries from your transaction data can improve both the measurement and reliability of one important payment metric in particular: approval rate. Calculated by dividing your total attempted transaction count by your total approved transaction count, approval rate tells you the percentage of transactions initiated in your system that actually put money in your pockets. Retry deduplication significantly impacts this metric by excluding failed retries that ultimately resulted in a successful transaction from your count of total and declined attempted transactions. Here's an example of how this could play out:

Your customer attempts a transaction and enters the CVV code of their credit card incorrectly. They doesn’t understand why the transaction failed and attempt it again three more times—receiving a failure each time. They eventually realize their mistake, fix the typo, and successfully complete the purchase. This one customer attempted five identical transactions: four transactions were declined with the decline reason code of decline_cvv_negative and one transaction succeeded. On that same day, you processed 95 other transactions, 10 of which failed.

If you didn’t apply retry deduplication to your transaction data, you’d include all five of Joe’s transaction attempts and all four declines in your approval rate calculations. As such, your approval rate for the day in question would be 86%: (100 attempted transactions – 14 declined transactions) / 100 attempted transactions = 86%

If you did apply retry deduplication, the four decline_cvv_negative transaction declines would not count toward your total transaction attempts or declines; only the successful transaction matters. Taking this into consideration, your approval rate would be 89%: (96 attempted transactions – 10 declined transactions)/96 attempted transactions = 89.6%)

Effectively, you’ve added nearly 4% to your total approval rate, because those declined transaction attempts aren’t actually problems your business needs to address. Instead, they were customer errors that were remedied by the customer and resulted in a successful sale. You don’t need to focus your business efforts here, so remove them from your approval rate calculation!

Retry Deduplication in Peacock and Canary

To power Peacock and Canary, Pagos ingests and aggregates your transaction data from multiple sources, thus allowing you to monitor your overall payments performance all in one place. In the service panels for both products, you can use filters to review only specific segments of your payments data:

• Peacock - Click the Deduplication filter option, then select Retries. This updates your data visualizations on the front end to exclude any duplicate transaction retries.
• Canary - When configuring a trigger, apply the Deduplication - Retries filter to instruct Canary to exclude duplicate transaction retries from the data set it monitors for anomalies.

On the back end, Peacock and Canary execute these filters by following these rules:

• Duplicate transactions are those for which all of the following information is identical:
  • Card information (BIN + last four digits + card expiration date)
  • Transaction amount
  • Merchant account
• Identical transactions must occur within 14 days of one another to be considered duplicate
• If all duplicate transaction attempts are successful, include them all in the data set
• If there are approved and declined duplicate transaction attempts, only include the successful transactions in the data set
• If all duplicate transaction attempts are declined, only include the first transaction in the data set

🚧

Data Considerations

This logic doesn’t account for every single duplicate retry in your transaction data. Because it hinges on card information (BIN, last four digits of the card number, and the card expiration date) it only serves to remove duplicate debit, credit, and prepaid card transactions from your data; other payment methods aren’t considered.

Additionally, if your payment processors fail to pass along all of the required card details with the transaction, Pagos won’t be able to identify the duplications.