Clearing and reconciliation

This guide covers the clearing-stage side of the transaction lifecycle.

Where a prior authorization exists, clearing follows that earlier authorization. In deferred-authorization or offline scenarios, the transaction may first become visible only at presentment and clearing.

For the end-to-end transaction map, use Transaction lifecycle.

That clearing stage is where the financial record becomes final for reconciliation purposes.

Presentment webhook

FINCI delivers the presentment event through a webhook once the transaction reaches the clearing stage.

That event is the point at which the integration receives the final transaction record for posting and reconciliation purposes.

In the common case, presentment can be linked back to an earlier authorization flow.

When the transaction follows an earlier authorization flow, the presentment payload includes authorization_id, which can be used to connect the cleared transaction back to that authorization.

Deferred-authorization and offline transactions

Not every transaction lifecycle starts with an authorization webhook.

In deferred-authorization or offline scenarios, such as an in-flight purchase, the card can be used when real-time authorization is not available. The financial event is then first seen only later, when presentment reaches FINCI for clearing.

In those cases, the integration should treat presentment as the starting point of the transaction lifecycle for posting, reconciliation, and downstream matching.

Where a prior authorization does exist, presentment should instead be linked back to that earlier authorization and treated as the final posted transaction event in that chain.

Reconciliation approach

Where an authorization exists, it should not be treated as the final financial record.

Reconciliation in this integration model depends on Payments API access to the FINCI core ledger.

Without Payments API access, this reconciliation flow is not available because the integrator cannot retrieve the FINCI ledger data needed to match cleared transactions.

When Payments API access is included, the reconciliation process typically works as follows:

• receive the presentment webhook
• where available, read the authorization_id from the webhook payload
• retrieve transactions from the relevant master account through the Payments API
• where an earlier authorization exists, match the ledger transaction to it using the authorization_id

Payments API usage itself sits outside the scope of these guides.

For deferred-authorization or offline transactions with no prior authorization, the reconciliation chain starts from presentment rather than from an authorization record.

An example ledger narrative may look like:

If the ledger entry starts with CRDS, it indicates a card-related authorization entry in the FINCI core ledger.

In this example, 251001435963146785 is the authorization_id carried from the presentment webhook into the ledger narrative.

What should be linked

A practical reconciliation process should be able to connect:

• the original authorization, when one exists
• either a reversal of the authorization before clearing, or the final cleared transaction
• any later refund (Return) or other credit, where a reliable link is available

Reversals

An authorization reversal cancels a previously approved authorization.

In this integration model, a reversal is received through the authorization webhook flow as an authorization message with authtype = Reversal.

Operationally, that should release any reserved funds or internal hold created for the original authorization.

The reversal should be linked back to the original authorization and treated as an unwind of the earlier authorization effect before presentment and clearing, rather than as a new cleared transaction.

Returns (refunds)

A return in this context represents a refund credit received after the original transaction flow.

In practice, that refund should also be posted and cleared through the transaction flow, rather than being treated as only an authorization-side event.

That refund may or may not carry a reliable link to the original transaction.

Where a reliable link is available, refunds should be matched to the original transaction so the integrator ledger and reporting remain coherent.

Reconciliation handling principles

• place reservations on approved authorizations if your model requires it
• release reservations on reversal
• book final movement on clearing
• post credits correctly for refunds
• distinguish webhook authtype values correctly: Cash, Goods, PaymentDebit, and QuasiCash as debit-side flows; PaymentCredit and Return (refund) as credit-side flows; Reversal as cancellation of a prior authorization; and GetContractInfo as a technical message
• keep a durable link between related transaction events using authorization_id and the corresponding ledger record