Reliable connectivity between payment systems, processors, hubs and networks, engineered around the outcome you cannot see rather than the two you can.
A payment succeeded, it failed, or you do not know. The third state is the one that costs money, and it is the one most integrations do not have a place to put. A timeout becomes an error, an error triggers a retry, and the retry creates a second payment that nobody authorised.
The failures below are different events with different correct responses. In most integrations they arrive as the same error, and the same retry logic runs against all six.
Every rail hidden behind one interface
So the exception handling is wrong for all of them.
Status arrives late, or not at all
And the system has no state for not yet known.
No end-to-end identifier
So the same payment cannot be traced across hops.
Retry logic that assumes failure
Which is how duplicate payments are made.
Transformation loss nobody measured
A field that did not map, discovered downstream.
Reconciliation is a monthly manual job
So a break is found weeks after it occurred.
A certificate expired on a Sunday
The most common self-inflicted payment outage.
Exceptions land in a mailbox
Rather than in a queue with an owner and an age.
Pick one payment path and ask what happens when the response never arrives. If the answer is that the payment is marked failed, or that the request is retried, the integration can create duplicates and the only question is how often. If the answer is that it enters a known state under the same identifier and is queried until resolved, the hard part has already been done. This question takes five minutes and it separates the two kinds of payment integration.
Any competent team can build a payment interface that works when everything responds. The engineering is in what happens when something does not, and that work is much harder to add afterwards than to design in.
So we start with the failure modes of each specific rail, design the identifier and state model around them, and test the integration by breaking it deliberately before it ever carries value.
Step 1
Map the payment ecosystem and every interface in it
Step 2
Trace each payment flow end to end, including its exceptions
Step 3
Analyse each rail and processor interface separately
Step 4
Design the end-to-end identifier and how it survives each hop
Step 5
Design the state model, including the unknown state
Step 6
Design message contracts and transformation, loss documented
Step 7
Design idempotency at every point that can be retried
Step 8
Build reconciliation into the integration, not after it
Step 9
Test by breaking it: timeouts, duplicates, partial responses
Step 10
Validate in parallel with the existing path before cutover
Step 11
Deploy with per-interface monitoring and a break process
Step 12
Operate: certificates, windows, volumes, network changes
Ask how long a reconciliation break can exist before anyone notices. If reconciliation runs daily and breaks are worked the same day, exposure is bounded. If it runs at month end, a systematic integration defect can run for weeks before discovery, by which time the volume is large, the customer impact is already out in the world, and the investigation starts from a position of not knowing when it began.
Grouped by responsibility. The state and reconciliation group is the one that determines whether the rest of it can be trusted.
Connectivity
Payment gateway integration, including authentication, session management and failure behaviour
Payment hub connectivity, where a hub exists, and hub-to-core interfaces per our Core Banking Integration page
Processor and acquirer integration across the arrangements your institution holds
Domestic and cross-border payment interfaces, engineered per rail rather than through a single abstraction
Secure network connectivity: tunnels, certificates, key management and allowlisting, with expiry monitored
Messaging and transformation
Message transformation between your internal model and each network’s format, with unmapped fields documented
Support for the message standards your networks require, including ISO 20022 where it applies to your markets
Validation at the boundary, so a message that will be rejected downstream is caught before it is sent
Transformation testing against the network’s own test facility where one is available
State and identity
End-to-end identifier design and the storage of identifier mappings across hops
Idempotency at every retryable point in the path
Transaction status integration, including asynchronous status, late status and status query interfaces
The unknown state, with its resolution path, escalation and ageing
Duplicate detection independent of the originating route
Returns, reversals and rejects handled as inbound events with their own states, since a payment that comes back is a new instruction rather than the absence of the original
Repair and investigation items routed to an owned workflow rather than to whoever notices, with the operational tooling itself covered on our Payments Applications page
Correlation of a return or a reversal to the original payment, which is the end-to-end identifier earning its cost a second time
Reconciliation and settlement data
Settlement data exchange and ingestion from each network and processor
Three-way reconciliation on count and value, on a defined cycle
Break identification, ageing and routing to an owned queue
Reconciliation data made available to finance and operations as our Operational & Financial Analytics page describes
Each of these is a different integration problem. Naming the specific thing that tends to go wrong is more useful than describing the connection, because the connection is rarely the hard part.
Real-time payment connectivity
An immediate, irrevocable payment with a short response window and no opportunity to reconsider.
Domestic transfers
Standard domestic credit transfers, usually with a defined processing cycle rather than an immediate outcome.
Cross-border payment messaging
Payments that cross networks and correspondents, with multiple intermediaries between instruction and credit.
Corporate payments
Payments instructed by a corporate customer through a channel or a direct connection, often in volume and often with approval workflow attached.
Bulk and file-based payments
High-volume files exchanged on a cycle, often the largest payment volume in the institution by count.
Payment gateway and processor connectivity
Card and alternative payment connectivity through a gateway or acquirer, usually on the merchant acquiring side of the institution.
Payment status distribution
Getting the outcome of a payment back to every system and channel that is waiting for it.
Settlement and reconciliation data exchange
Ingesting what each network says happened, and comparing it with what you believe happened.
Ask what the system does when the screening service does not answer. In a surprising number of institutions nobody knows, and the behaviour was decided by whoever wrote the error handler. It is a compliance decision with a technical implementation, not the reverse, and it should be written down with a named owner. The same question applies to every synchronous dependency in a payment path.
We work within your existing platform decisions, network arrangements and hosting policy. Payment connectivity has a physical dimension that most integration work does not, and it fails in ways that have nothing to do with code.
Architecture components
Boundary adapters
One per network or processor, with that rail’s failure behaviour explicit.
Message transformation
Internal model to each network format, loss documented.
Payment state store
Authoritative status, including held and unknown states.
Idempotency and identifier service
End-to-end identity and mapping across hops.
Queues and event streams
For asynchronous status and for store-and-forward.
Secure connectivity
Tunnels, certificates, keys, allowlisting, monitored expiry.
Reconciliation engine
Three-way matching on count and value with break ageing.
Observability
Per interface, per rail, per flow, as section 8 sets out.
Messaging standards
ISO 20022 where it applies to the networks and markets your institution operates in
Legacy and proprietary formats where a network or processor still requires them, which is most estates
File-based exchange over secure transfer where that is the supported interface
API and event interfaces where a network or hub provides them
And translation between all of the above, since a real estate carries several at once and will for years
Three properties matter more than everything else in a payment path: a payment cannot be altered after instruction, cannot be executed twice, and cannot disappear without anybody knowing. Each one is a specific engineering control rather than a general assurance.
Message integrity
Signing or equivalent, so alteration in transit is detectable.
Secure transmission
Encryption in transit, mutual authentication, managed keys.
Idempotency and duplicate prevention
At the boundary, in transit and at the destination.
No silent loss
Persistence before acknowledgement, with recovery on restart.
Access control
Who can submit, resend, amend, cancel or release, with segregation.
Auditability
Every instruction, transformation, outcome and manual action.
Resilience
Defined behaviour when a network, screening service or core is down.
Change control
Interface change governed, versioned and tested against the network.
Payment monitoring tends to collect what is easy: interface availability, message counts, latency. The four measures below are the ones that correspond to money at risk, and they are the ones worth waking somebody for.
The four that warrant an alert
Unknown-state payments by count and by age, because this is the direct measure of exposure and it is almost never on a dashboard
Reconciliation breaks by age and value, with an alarm on any break older than its agreed resolution window
The expected file or message that did not arrive, since absence generates no error and is invisible to every other measure
And duplicate detections, because a rise means retry logic has started behaving badly somewhere upstream
The rest, which belong on a dashboard and in an operational review
Interface availability and message delivery success per network and processor
Processing latency per rail, as percentiles, since the average hides the payments that missed a window
Exception volumes by type and by rail, trended rather than counted
Batch and file completion against its expected schedule
Held payment volumes and ages, including payments held for screening
Certificate and credential expiry horizon across every interface
Manual intervention counts, which are the clearest signal of where the integration is weakest
Ask for the count of payments currently in an unknown state, and the age of the oldest. If the number cannot be produced, the state is not modelled and those payments are being resolved by customer complaint and reconciliation break. If it can be produced and the oldest is days old, there is a resolution path with no escalation. Both answers are more informative than any availability figure on the dashboard.
Outcomes depend on your rails, your volumes and your current estate. These are the changes the work is aimed at.
Duplicate payments stop being created by retry logic, because resend is safe by design
An unknown outcome resolves automatically in most cases and escalates with context in the rest
A payment can be traced end to end in minutes, because it carries one identifier through every hop
Reconciliation breaks are found daily rather than monthly, which bounds the exposure of any defect
Exceptions arrive in an owned queue with an age rather than in a mailbox
Manual interventions fall, and the ones that remain point at the next thing to fix
Certificate and credential expiry stops causing weekend outages
And the behaviour when a network, a core or a screening service is unavailable is a decision somebody made and wrote down
Bring us one payment path, including its exception handling and its reconciliation, and we will map the failure modes, identify where a duplicate or a silent loss is possible, and define a first piece of work with an acceptance test you can run yourself.
CaliberFocus builds payment connectivity that treats the unknown outcome as a first-class state with its own identifier, resolution path and queue. We carry one identifier end to end, make every retryable point idempotent, keep per-rail behaviour explicit, and prove money moved through three-way reconciliation against the network.
- The unknown outcome modelled with a resolution path and escalation
- One end-to-end identifier carried through every hop
- Three-way reconciliation on count and value, on a defined cycle
- Certificates and credentials inventoried with monitored expiry
Security & Compliance
