Retries
Authorization retires
e.g. MsgType 0100
From time to time a transaction is lost in transit. It is therefore necessary that it can be retried. Since the Authorization System does not offer idempotency it is VERY IMPORTANT that retries are performed correctly.
A retry transaction MUST NOT be identical to the transaction that is being retried. The mandatory parameter MsgID must differ from the previous transaction. Optionally it should be increased by one, but depending on the merchant/processor implementation that might not be possible. First and foremost it must be different from the value in the previous transaction.
There are measures in place to avoid charging the cardholder multiple times. But the authorizaiton transaction travels a long way and through multiple systems. Depending on where a transaction is lost, it is not always possible to interpet the current status correctly.
Here is one example:
An authorization is processed almost all the way from the merchant and back. Not until on the network between the merchant and acquirer it gets lost. Now in the eye of the Authorization System the transaction was successful.
But the merchant does not recieve a response, so he retries.
This time the transaction is dropped from the network between the acquirer and the card scheme.
The customer has been waiting a long time and no response yet, so he cancels. That triggers a reversal/cancellation request to the acquirer.
The acquirer has no way of knowing if the merchant is trying to reverse/cancel the first try or the second.
In that case the Authorization System responded with response code T0, unable to locate previous transaction, not because no transaction can be matched to the reversal, but because more than one transaction is matched.
Reversal retries
e.g. MsgType 0400
Since the identifiers in a reversal request are echoed from the authorization, retries can and must be identical.
Retry Blocking Policy
Our system includes a retry blocking policy targeting specific Merchant Advice Codes (MACs) that indicate a permanent or mandated denial from the card issuer. This policy prevents futile and costly retry attempts on transactions that are certain to fail again.
Blocked Merchant Advice Codes (MACs)
Transactions that receive one of the following MACs are automatically blocked from any subsequent retry attempts for the same payment and card combination:
| MAC Code | Description | Blocking Action |
|---|---|---|
| 01 | Do Not Try Again | Blocked |
| 05 | Suspected fraud, do not try again | Blocked |
| 06 | Payment cancellation, do not try again | Blocked |
Response for Blocked Retries
If an authorization request is submitted for a transaction that was previously declined with one of the above MACs, our system automatically blocks the request.
Instead of routing the request to the issuer, you will immediately receive the following response:
- Response Code: TJ
- Response Description: Authorization was previously declined with a 'Do not try again' Merchant Advice Code and has therefore been blocked.
This allows your systems to immediately identify retries halted by this policy and ensures you do not waste resources or incur fees on transactions that will not be approved.