Processing Error Decline (Code 06/12)
Processing error declines (ISO 8583 codes 06 and 12) indicate a technical problem on the payment processor's or acquiring bank's side during transaction processing. Unlike other declines, this isn't a decision to reject the payment — it's a system failure that prevented the transaction from being evaluated at all. These soft declines have an excellent 90-95% recovery rate because the underlying systems are usually fixed quickly.
Affected Percentage
~4% of all declines
Recovery Rate
90-95% recoverable
Recommended Action
Retry with strategy
Common Causes
Payment processor system error
A bug, overload, or temporary failure in the payment processor's software prevented the transaction from being forwarded to the card network.
Acquirer bank technical issue
The acquiring bank (your bank) experienced a technical problem while routing the transaction to the card network.
Malformed transaction data
The transaction request contained improperly formatted data that the processor couldn't parse. This is usually a coding issue in the merchant's integration.
Processor capacity exceeded
During peak transaction volumes, the processor may hit capacity limits that cause some transactions to fail with processing errors.
Recommended Retry Strategy
Timing
Retry after 1-2 hours. Processing errors are usually resolved quickly. If the first retry fails, wait 4-6 hours for the second attempt.
Max Retries
3 retries within 24 hours
Reasoning
Processing errors are technical glitches, not decision-based declines. The systems are designed to self-heal or be fixed by operations teams. A retry after 1-2 hours almost always succeeds.
Best Practices
- 1
Retry after a short delay (1-2 hours) — processing errors are the most transient type of decline.
- 2
If you see processing errors on multiple transactions simultaneously, check your payment processor's status page for known incidents.
- 3
Verify your integration code if you see persistent processing errors on your transactions but not industrywide.
- 4
Do not contact the customer — this is a system issue, not a card or account problem.
- 5
Log detailed error responses from your processor to help diagnose whether the issue is on your end (malformed data) or their end (system failure).
How Rezoki Handles This Automatically
Rezoki classifies processing errors as the highest-priority soft decline category and schedules rapid retries — first at 1 hour, then at 4 hours, then at 12 hours. Rezoki also correlates processing errors across your entire customer base to detect processor-wide incidents versus isolated failures. During a detected incident, Rezoki intelligently queues all affected transactions and retries them in a batch once the processor has recovered, rather than competing for capacity during the outage. No customer notification is ever sent for processing errors.