A regional payment processor serving banks in Pakistan and the Gulf (name withheld under NDA)
TranzAxis Payment Gateway — an internal delivery codename, not a commercial product name.
The problem
The client was processing on a platform where retries were not idempotent, which produced a steady trickle of duplicate settlements that cost more to investigate and resolve than the transactions were worth.
Reconciliation ran nightly. A break discovered at 2am was a break that had been accumulating for up to twenty-four hours, and tracing it meant reconstructing a day of activity from logs.
Constraints we had to design within
- Authorisation latency budget was fixed by scheme requirements and could not be traded away.
- Scheme certification test cases and calendar were external dependencies with no flexibility.
- Cardholder data environment scope had to be minimised for the client's own PCI-DSS assessment.
- Migration had to be incremental — no cutover night.
Approach
Idempotency as a platform property
Every mutating operation takes an idempotency key, and the switch enforces it at the boundary rather than trusting callers. This is unglamorous and it eliminated the duplicate-settlement class of defect entirely rather than reducing its frequency.
Continuous reconciliation
Reconciliation moved from a nightly batch to a continuous process. Breaks surface within minutes against a narrow window of activity, which changes investigation from an archaeology exercise into a lookup.
Tokenisation to shrink assessment scope
Primary account numbers are tokenised at the edge so they do not propagate into systems that have no business holding them. This narrows the cardholder data environment, which directly reduces the surface the client's Qualified Security Assessor has to examine.
To be precise about the boundary: we engineer to PCI-DSS requirements. The certification is issued to the entity operating the environment following QSA assessment — it is the client's certificate, not ours.
Certification planned as a schedule dependency
Scheme certification is more often the constraint than the engineering is. Test-case coverage and mandated message fields were planned against the certification calendar from the start rather than discovered during it.
Engineering notes
Idempotency enforced at the database, not in application code
The failure that matters in payment engineering is the ambiguous one. A timeout tells you nothing about whether the payment executed — only that you did not hear back. If a retry is treated as a fresh instruction, money moves twice, and on an irrevocable rail that becomes a recovery case rather than a rollback.
Every initiation carries a client-generated idempotency key persisted before the outbound call, with uniqueness enforced by a database constraint rather than by an application-level check. Application-level checks lose to concurrency: two workers can both read "not seen" before either writes. A constraint cannot be raced.
This is well-understood and remains the most common serious defect we find in payment code, precisely because it is invisible until the day the network misbehaves.
Separating the ledger from the payment status
A single mutable status field is the design that makes incidents unresolvable. When the rail and your own records disagree — and eventually they will — you need both positions to diagnose which is wrong.
The ledger records what is believed true financially. The payment status records what the rail last reported. Keeping them distinct means a discrepancy is a visible, queryable state rather than a value that was silently overwritten by whichever update landed last.
Reconciliation as a process, not an error handler
Any payment left in a non-final state is driven to a final one by an explicit reconciliation process using status inquiry, rather than by assumption or by waiting for a customer to complain.
The design principle is that the system, not the customer, is responsible for noticing. A payment that has been in flight for an hour is an incident; if nothing in the architecture surfaces that, the support queue is functioning as the monitoring system.
Outcome
Duplicate settlements arising from retry behaviour were eliminated by construction. Reconciliation breaks are detected in minutes rather than at end of day.
The platform passed scheme certification within the planned window, and the reduced cardholder data environment scope simplified the client's subsequent PCI-DSS assessment.
Figures above are drawn from delivery records held under NDA and are pending independent confirmation. Where a figure cannot be evidenced it will be removed rather than qualified.