News and analysis
Payment reconciliation: linking payment attempts, cancellations and records
Map Payment Intents, Payment Records and attempts, interpret Stripe cancellation reports and manage an actionable reconciliation queue.
The accounting system marks an order paid, the provider shows a failed attempt and support reports a cancellation. All three records may refer to the same order while describing different events. Payment reconciliation starts by separating these entities: an intention to pay, an individual attempt, a reported outcome and an actual movement of money.
Stripe API version 2026-09-30.endive introduces Payment Records changes that help represent links and states more precisely. They provide additional integration data, but do not replace financial accounting rules. A useful upgrade makes discrepancies explainable and associated records findable; it does not establish that reconciliation has become automatic.
Link the Payment Intent to its Payment Record
The Stripe payment_record changelog describes a new expandable property on Payment Intent. It contains the identifier of the associated Payment Record. Stripe says that an integration using Payment Records can retrieve the related record directly through the Payment Intent object without a separate association lookup.
This is a conditional capability for integrations that use Payment Records. It does not show that every shop order already has a complete accounting record or that the association automatically verifies the amount. The application still needs its internal order identifiers, provider links and missing-data rules.
Start with a mapping: internal order, Payment Intent, Payment Record and individual attempts where relevant. Retain entity identifiers rather than matching records solely by email, similar amount or nearby timestamps. Those attributes may justify investigation, but are insufficient for automatic merging.
Cancellation becomes a reportable outcome
In Stripe's reporting canceled payments publication, canceled is added to outcome when reporting a payment or payment attempt. The previously listed values are guaranteed and failed. Setting outcome: canceled requires the canceled parameter containing a canceled_at timestamp.
Stripe describes creating a Payment Record for a canceled payment with one call. For an existing record, an integration can report a canceled attempt without the previous two-message sequence. This changes how an outcome is recorded. It does not mean that submitting the report itself cancels a payment operation or issues a refund.
An internal “canceled” status therefore needs an exact definition. A canceled order, a canceled payment attempt and a completed refund are different states. If an application stores all of them in one field, the new API capability may merely add another value to an already ambiguous model.
Check consumers of wallet.type
A third update concerns Link wallet details on Payment Records and Payment Attempt Records. Stripe adds the link type and an object with the optional, nullable funding_source_group field for Link card payments. The source describes this identifier as opaque and immutable, resolved at confirmation.
An integration that exhaustively handles wallet.type must account for the new value. An absent funding_source_group must not automatically become a payment failure: the field can be null. Do not interpret the identifier as a bank name, customer name or accounting account; the announcement assigns no such meaning.
For reconciliation, the practical concern is that a parser should not discard a record when a new wallet representation appears. A matching funding source group does not replace a payment identifier or prove that two operations belong to one order.
Compare records with the same meaning
Imagine a subscription where a customer makes two payment attempts: the first fails and the second produces a confirmed outcome. This is an illustrative scenario. The system should retain both attempts and separately identify the basis for treating the obligation as fulfilled.
For each reconciled operation, retain identifiers, amount, currency, event time, receipt time and a well-defined state. Compare amounts in agreed units, apply a consistent time convention and preserve unknown outcomes until sufficient evidence arrives. Agree with the accounting owner which source determines the final monetary state.
The comparison boundary also matters. A payment's operational outcome, provider settlement, fees and accounting entry may be recorded at different times. New Payment Records fields do not make those amounts equal. Compare equivalent entities and explain which timing differences are expected.
Turn a discrepancy into an actionable task
A report saying “does not match” is insufficient. Separate reasons: missing association, unknown state, amount mismatch, late event or a financial operation requiring review. Each needs an owner and a safe next action.
If a record is missing, do not mark an order paid just to clear the report. When a cancellation is reported, first establish what was canceled and whether a separate monetary movement exists. For rechecking, retain original identifiers and the previous decision. This makes the history understandable to support and finance.
The workflow can become part of an internal business system that shows ownership and the next task. Data transfer through API integrations requires explicit state contracts. The custom API architecture description provides context about models and shared resources, but does not establish use of Payment Records in that project.
Validate meaning before release
When upgrading, check the new association, a canceled outcome with its timestamp, the link enum value and the nullable field. Then exercise business scenarios: two attempts for one order, a missing record, a delayed message and cancellation without refund. The goal is to ensure that a technical event is not presented as financial confirmation.
For subscription products, also review the subscription cancellation flow. Stopping future charges and determining the outcome of a past payment require different rules. A shop should preserve the same distinction in order edits and returns.
Start with a small discrepancy queue the team can actually investigate. Measure unresolved-case age, association completeness and reasons for manual corrections. That provides a basis for further automation without concealing uncertainty behind a single green status.