Transactions
/
Transaction lifecycle

Transaction lifecycle

Find a transaction use case — purchases, amount changes, clearing, reversals and matching.

This guide provides the high-level transaction sequence used across the portal.

Follow the purchase below, then select another path in the overview. Detailed rules are linked from each use case.

Start with one purchase

StageWhat happensWhat your integration does
Authorization
The network asks whether the card can pay.
If integrator-managed, approve or decline. For a debit approval, reserve the local amount if your model uses client-side holds.
Clearing / presentment
The merchant submits a charge; FINCI sends its clearing record.
Post the charge once and release the full matching hold.
Settlement
The network settles financial obligations between issuer and acquirer.
Follow the agreed program funding and reconciliation arrangements.

An approved debit authorization can create a reservation; it is not a posted debit. A presentment is a clearing record; it does not confirm that network cash settlement has completed. The authorization field amount_settlement is an amount expressed in a currency, not a separate settlement event.

Purchase: EUR 10.65

This example reserves EUR 10.65, confirms the approval and later posts the charge. Open the complete messages below. Identifiers, dates, locations and merchant names are fictional; financial values and references are preserved.

  1. An initial Goods authorization has id: 900100100000000000, response_code: "" and accounts_local[0].account_amount: 10.65 in EUR.

  2. For integrator-managed decisioning, atomically check available funds and reserve EUR 10.65 before returning HTTP 200 with {"status":"success"} within 3 seconds. A decline requires HTTP 403 with {"status":"error"}.

  3. The confirmation uses the same id, with response_code: "Approved" and local amount -10.65. Keep the existing hold; do not reserve or debit it again. Release a provisional hold if the resulting outcome is a decline.

  4. The presentment has its own id: 900100200000000000, authorization_id: "900100100000000000", sign: "Debit" and local amount -10.65. Post the debit once and release the full hold in the same accounting operation.

Reserve EUR 10.65 once. Confirmation keeps the same hold. Presentment posts EUR -10.65 and releases the full hold.
Complete webhook messages

Download these complete messages (JSON)

Identifiers, merchant names, approval codes, dates and locations are fictional. Financial values, field types and references are preserved.

The diagram follows the reservation and the posted account movement for this purchase. See Authorization flow for the exact amount fields and Clearing and reconciliation for charges that clear in parts.

Presentment normally arrives in 1–3 business days, when the merchant and acquirer submit clearing. See presentment timing for the common 7-day final-authorization and 30-day preauthorization windows.

Overview diagram

An approved purchase normally goes from authorization to presentment and posting. A reversal releases an eligible unposted hold. Some purchases first appear at clearing. A refund is a later credit flow. Network cash settlement is a separate stage.

How to read this lifecycle

  • the most common path starts with an authorization request and later reaches presentment and clearing
  • a reversal releases all or part of an eligible authorization hold; it does not refund a posted debit
  • presentment can be the first event received; a supplied authorization reference may still be awaiting its earlier record, while an empty reference remains unlinked
  • a refund (Return) is a later credit flow and may be linked to the original transaction where that relationship is available

Guide boundaries

  • use Authorization flow for real-time decisioning, advice messages, timeout behavior, and authorization-stage reversals
  • use Clearing and reconciliation for posting, holds, presentment-first transactions, refunds and reconciliation
  • use Webhook handling for delivery behavior, retries, idempotency, and webhook consumer design

The Core data model guide defines the records themselves. This guide only shows how the transaction lifecycle can move between them.

Built with