Code 79: Already Reversed

Decline Code 79: What 'Already Reversed' Means for Merchants

Decline code 79 means a reversal of this transaction has already been processed. The bank is rejecting either a duplicate reversal attempt or a charge on an authorization that has already been cancelled. In most cases it's a signal that something in the transaction flow sent the same request twice, and the first one already worked.

What Does Decline Code 79 Mean?

When a merchant voids or reverses a transaction, the bank marks that authorization as cancelled. If another reversal request comes in for the same transaction, the bank returns code 79: this has already been handled.

That's usually good news. It typically means the original reversal went through successfully and the system is just catching a duplicate. But code 79 can also appear in situations where the transaction state is unclear, particularly when system timeouts or integration errors make it uncertain whether the first request completed. In those cases, a 79 is the confirmation that it did.

Where it requires attention is when code 79 appears and the expected funds haven't been returned to the customer. That scenario points to a discrepancy between what the bank processed and what the merchant's system recorded, and it warrants immediate contact with your processor.

Reversal vs. Void vs. Refund: Understanding the Difference

These three terms describe related but distinct operations, and code 79 is specific to two of them.

Reversal cancels an authorization before it settles, typically within the same processing day. The funds were never captured, so nothing needs to be returned. The authorization simply ceases to exist.

Void cancels a transaction that's been submitted to a batch but hasn't settled yet. Like a reversal, it prevents the funds from being captured rather than returning them after the fact.

Refund returns funds to the cardholder after a transaction has already settled. Money was captured, posted to the account, and is now being sent back through a separate credit transaction.

Code 79 relates to reversals and voids. A refund on a settled transaction is a different operation entirely and won't produce a 79.

Common Causes of Decline Code 79

• Automated retry logic sending a duplicate reversal request. If a system sends a reversal, doesn't receive a clear confirmation, and retries, the second request hits an authorization that was already cancelled by the first.
• Manual void attempted on an already-voided transaction. An operator voids a transaction, the system doesn't update visibly, and they void it again. The second attempt returns a 79.
• System timeout causing the original reversal to be sent twice. The first request timed out before returning a response, the system treated it as a failure and resubmitted, but the original had already processed.
• Integration bug causing duplicate API calls. A race condition, missing idempotency key, or error in the integration logic sends the same reversal request multiple times.
• Batch settlement processing error. During batch processing, a reversal that was already applied gets flagged again in error.

How Merchants Should Handle Decline Code 79

1. Check your transaction logs to confirm the original reversal processed successfully. A code 79 is usually confirmation that the first reversal worked. Verify in your system and with your processor's records that the transaction is in a cancelled or voided state.
2. Do not send another reversal. The transaction is already cancelled. Additional reversal attempts will return the same code 79 and accomplish nothing.
3. If the funds have not been returned to the customer, contact your processor immediately. A code 79 combined with funds that haven't been released points to a reconciliation issue. Your processor needs to investigate the discrepancy between the bank's records and your system's records.
4. Audit your retry logic to prevent duplicate reversal calls. If code 79 is appearing regularly in your logs, your integration is likely sending duplicate requests. Implementing idempotency keys on reversal API calls prevents the same request from being processed twice regardless of how many times it's sent.

Frequently Asked Questions About Decline Code 79

Does code 79 mean the customer will be charged? No. Code 79 means the transaction has already been reversed, which means the authorization is cancelled and no charge will be captured. If anything, a code 79 is confirmation that the customer will not be charged. The concern would be the opposite: if you're seeing a code 79 but are uncertain whether the original transaction settled before the reversal, check with your processor to confirm the final transaction state.

How do I know if my reversal went through before I got a code 79? Check your transaction logs and your processor's dashboard. A successfully processed reversal will appear as a voided or cancelled transaction in your records. If the original reversal is confirmed in your system, the code 79 is simply the bank confirming it won't process a duplicate. If your records are unclear, your processor can pull the transaction history and confirm exactly what state the authorization is in.

Can code 79 cause a chargeback? Not directly. A code 79 means the transaction was reversed before settlement, so there's nothing captured for a cardholder to dispute. The chargeback risk would come from a scenario where the merchant's system shows a reversal but the bank didn't process it correctly, resulting in a charge the customer wasn't expecting. That's a reconciliation issue rather than a code 79 issue, and it's why verifying the transaction state when a 79 appears alongside unexpected customer charges is important.

How do I fix a duplicate reversal issue in my payment integration? The standard solution is implementing idempotency keys on your reversal API calls. An idempotency key is a unique identifier attached to each request that tells the processor to treat any duplicate submissions of the same key as the same request rather than a new one. If your payment gateway or processor supports idempotency keys, using them on all reversal and void calls prevents duplicate processing regardless of retries or timeouts. If you're seeing consistent code 79 errors, reviewing your retry logic and ensuring reversals are only triggered once per transaction is the next step.

Related Decline Codes

Code 79 is specific to the reversal and void flow. These related codes cover adjacent transaction state and processing issues:

• Code 06 — General Error. A broader processing error that can sometimes accompany transaction state issues.
• Code 12 — Invalid Transaction. A transaction validity error, sometimes triggered by attempting an operation on a transaction in the wrong state.
• Code 05 — Do Not Honor. The bank's catch-all decline, occasionally returned instead of a more specific code.
• Code 51 — Insufficient Funds. A balance issue on a forward transaction, unrelated to reversals.
• Code 30 — Format Error. A data formatting issue in the transaction request, a different kind of technical failure.
• Code 13 — Invalid Amount. An amount field error, relevant if a reversal is submitted with an incorrect amount.
• Code 14 — Invalid Card Number. A card number issue, unrelated to reversal state.
• Code 58 — Transaction Not Permitted to Terminal. A merchant configuration issue, not a transaction state issue.