Routing and reconciliation need one evidence chain

Routing decides where a payment goes. Reconciliation tests whether the recorded operational and financial evidence agrees afterward. Treating them as separate worlds creates blind spots.

Begin the record at route selection

Store the payment context, policy version, selected pipeline and provider identifier before the request leaves the orchestration layer. That route identity should remain attached to subsequent status changes, callbacks, refunds and related operations. Use the route diagnostic walkthrough to reconstruct the decision and the provider attempts behind a disputed record.

Preserve every attempt, not only success

Cascading can create several provider attempts for one customer action. Finance and operations need to know which attempt was submitted, completed, reversed or left unresolved. Collapsing the sequence into one final status can create false matches and missed exceptions.

Match reports to the same identifiers

Import or review PSP reports against the provider and merchant references recorded in the payment history. Compare amounts, currencies, fees, timestamps and status semantics. Keep expected settlement separate from the PSP's settlement responsibility and actual transfer.

Route exceptions to the right owner

A missing record may indicate integration mapping, report scope, timing or provider processing. Attach the evidence and next action to the exception, then assign it to merchant finance, PayStar technical operations or the PSP as appropriate.

Include enough evidence for the next team

Before handing over a reconciliation exception, record:

• The merchant payment reference, pipeline and PSP attempt reference.
• The PSP report filename, reporting period and timezone, plus the matching row or the reference that could not be found.
• The expected and reported amounts, currencies, fees and statuses, with each source identified.
• The checks already completed, the unresolved question and the named owner of the next action.

Apply the agreed payment data access boundaries when sharing this evidence. Preserve source values so the receiving team can trace the exception back to the original records.

Worked example: three reconciliation exceptions

These fictional records illustrate the investigation process. Assume one PSP account, one pipeline and GBP throughout, with no currency conversion. The amounts, references and fee assumptions are invented for this example and do not describe PayStar pricing or a customer result.

1. A fee difference: GBP 0.50 to explain

Merchant payment EX-101 maps to provider attempt PSP-A101. Both records show a gross amount of GBP 100.00. The assumed contract fee is GBP 2.00, so the expected net amount is GBP 98.00. The matching report row shows a fee of GBP 2.50 and net GBP 97.50: GBP 0.50 below the expectation.

Next check: merchant finance verifies the fee terms effective for that transaction and any applicable adjustments against the original report. If the higher fee remains unexplained, send the PSP the matched references, fee calculation and source row. Keep the difference open until evidence explains it; changing the expected amount alone does not resolve the cause.

2. A reporting cut-off: the event belongs to a later period

For this example only, assume a report includes events by their booking timestamp from 10 September 2026 at 00:00 UTC up to, but excluding, 11 September at 00:00 UTC. Payment EX-102 completes at 23:58 UTC on 10 September, but its financial event is booked at 00:05 UTC on 11 September. Under this rule, the event is outside the first reporting window.

Next check: confirm the actual report's event basis, timezone and batch rules, then look for the same provider reference in the appropriate later report. Record a timing explanation only after checking the booking evidence. A payment completion timestamp alone does not establish when a settlement report should include it.

3. A missing row: the reference still needs investigation

Payment EX-103 has a recorded successful attempt, PSP-A103, but no matching row is found in the selected report. There is no booking evidence yet to explain the absence.

Next check: confirm the merchant account, report completeness, period and eligible event types. Check the provider reference mapping and every attempt in the route history. If the record should be in scope and is still absent, assign an owner and escalate with the original report and attempt evidence. An absent row alone does not prove that funds were lost or settled.

Use the provider's own report definitions when applying these checks. For example, Adyen's Settlement details report distinguishes creation and booking dates, references, journal types and fee fields. Stripe's Payout reconciliation report defines gross, fee and net amounts and separate transaction and payout dates. These references explain report semantics; the fictional example above uses its own stated assumptions.

Feed exceptions back into route operations

Repeated reconciliation differences can expose a status mapping gap, callback problem, provider report limitation or an operational rule that needs attention. Summarise patterns by pipeline and payment lifecycle, then send them to the team that can change the cause. Do not silently correct the financial view while leaving the route evidence inconsistent. The resolution should update both the exception and the relevant integration, monitoring or provider playbook so the next payment carries better evidence.

Reconciliation is stronger when the financial record can point back to the exact route decision and every provider event that followed.