How Should You Respond to a Payment Incident?
A payment incident is any event that disrupts payments or puts money or data at risk: a batch of duplicate debit orders, a card testing attack, a suspected data breach, a processor outage, or compromised account credentials. Incidents involving money are unforgiving — every hour of delay can mean more failed collections, more fraudulent transactions or more customers double-charged — so having a response approach ready matters more than in almost any other part of the business.
The good news is that most payment incidents follow the same response structure, regardless of the cause. What differs is who you notify and how you remediate.
What are the phases of incident response?
- Detect and confirm. An alert, a customer complaint or a reconciliation mismatch raises the flag. Confirm it is real before acting — a signal that pattern-matches a known failure can have a different cause.
- Contain. Stop the damage from growing: pause a collection batch, disable a compromised API key, enable emergency fraud rules, or take an exploited endpoint offline. Containment usually has to happen before the root cause is fully understood.
- Assess impact. Establish which transactions, customers and amounts are affected, over what period. Reconciliation data and audit logs are your primary tools here.
- Remediate. Fix the root cause and correct the money: refund duplicates, reverse erroneous collections, or reprocess failed payments.
- Communicate. Notify affected customers, your payment provider and bank, and — where legally required — regulators.
- Review. Once resolved, run a blameless post-incident review: what happened, why, how detection and response could be faster, and what prevents recurrence.
What do common payment incidents look like?
- Duplicate collections or charges — usually a batch submitted twice or a retry bug. Contain by halting the batch process, then refund or reverse proactively before disputes start arriving. Idempotency controls prevent recurrence; see idempotency and duplicates.
- Fraud attack — such as card testing against your checkout. Contain with velocity rules and blocking, refund fraudulent successes, and review the attack surface. See card testing and velocity checks.
- Compromised credentials or account takeover — revoke keys and sessions immediately, freeze payouts, re-verify banking details. See account takeover and social engineering.
- Data breach involving personal information — contain the exposure, then remember that POPIA requires notifying the Information Regulator and affected data subjects when personal information is compromised. If card data may be involved, your acquirer and the card schemes have their own notification and investigation requirements under PCI DSS.
- Provider or bank outage — mostly about communication and recovery: queue or retry payments safely once service resumes, and reconcile carefully afterwards to catch payments stuck in unknown states. See retries and stuck payments.
Who needs to be notified, and when?
| Incident type | Notify |
|---|---|
| Duplicate or erroneous collections | Affected customers, your payment provider |
| Fraud attack | Your payment provider; bank fraud line if funds moved |
| Personal information breach | Information Regulator and affected data subjects (POPIA) |
| Card data compromise | Your payment provider and acquirer (PCI DSS obligations) |
| Any incident affecting collections or payouts | Your finance team, so reconciliation expects the corrections |
Communicate with customers early and plainly. A customer who hears about a duplicate debit from you, with a refund already in progress, rarely disputes; a customer who discovers it on their bank statement goes straight to the bank.
What should you prepare before an incident?
- Alerting on failure rates, decline spikes, duplicate patterns and reconciliation breaks, so you detect problems in minutes.
- Audit trails and logs that let you reconstruct exactly which transactions were affected. See logging, masking and audit trails.
- Emergency contacts for your payment provider and bank, known before you need them at 2 a.m.
- The ability to stop things — a way to pause batches, disable keys and halt payouts quickly.
- A simple written runbook covering the phases above, because decision-making under pressure is when structure helps most.
Related topics
KYC, AML and POPIA
The compliance obligations behind payments in South Africa, including FICA KYC checks, anti-money laundering rules, sanctions screening and POPIA.
Card Chargebacks
How the card chargeback process works from cardholder claim to final ruling, the common reason codes, and how merchants can reduce chargeback rates.