Clearing And Reconciliation

After an authorization is approved, the transaction later moves through the Mastercard clearing process.

That later phase 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.

The presentment payload includes authorization_id, which can be used to connect the cleared transaction back to the earlier authorization flow.

Reconciliation approach

Authorization 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
• read the authorization_id from the webhook payload
• retrieve transactions from the relevant master account through the Payments API
• match the ledger transaction to the earlier authorization using the authorization_id

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

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
• the final cleared transaction
• any reversal of the authorization
• any later return or credit

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 rather than as a new cleared transaction.

Returns

A return represents a credit received after the original transaction flow.

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

Where possible, returns 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 returns
• distinguish webhook authtype values correctly: Cash, Goods, PaymentDebit, and QuasiCash as debit-side flows; PaymentCredit and Return 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