Payment Processing
Overview
In this section, we'll explain how to implement your transaction processing backend system with Open Fabric's transaction authorization host.
In a nutshell: As part of your integration with Open Fabric, you receive real-time authorization requests for transactions on tokenized accounts; you then receive clearing data (batches) and finally settlement (funds movement).
-
Authorization (real-time): When a customer pays on a merchant's website or in-store using an account tokenized in our platform, the transaction is routed via the merchant's acquirer to the card network, which sends it to our authorization host. We forward the request to you as an "authorization message". You must respond in real time with an approval or decline.
-
Clearing (batches): After a transaction is approved, the merchant's acquirer submits it for clearing: the exchange of transaction data in batches through the card networks, typically multiple times per day. You are informed of what will be settled but do not approve individual items at this stage.
-
Settlement (funds): The card networks then perform settlement: crediting and debiting the net amounts of all participants' bank accounts. Depending on your setup, the card networks settle you directly or settlement is reflected on your BIN sponsor (the bank that holds the BIN range on your behalf), who in turn settles with you. Settlement usually happens once per day per settlement currency.
See the table below for how the three phases differ.
| Phase | Message types | Your role |
|---|---|---|
| Real-time Authorization | Authorizations (incl. reversals) | You approve or decline each request in real time. |
| Clearing | Authorizations (incl. reversals and expiry), Refunds (incl. reversals and expiry), Chargebacks (incl. reversals and challenges), Fee Collections | You receive batch files; no approval needed. Typically multiple times per day. |
| Settlement | Authorizations (incl. reversals), Refunds (incl. reversals), Chargebacks (incl. reversals and challenges), Fee Collections | You receive a settlement report once per day with total amounts and line-by-line records; funds move. |
Pre-Authorization vs Final Authorization
Authorization can be two-step (pre-auth then capture) or one-step (final auth). Merchants (or their acquirers) send one or the other; your host must support the type they send.
- Pre-Authorization: The merchant asks you to authorize the transaction and hold (ring-fence) the amount on the customer's balance. The amount is not yet sent for clearing and settlement. The merchant must later capture the amount in full or in one or more partial captures. Capture can occur up to 30 days after the pre-authorization in some cases.
- Final Authorization: The merchant requests an authorization for an exact amount, which can immediately be deducted from the customer's balance. These transactions do not always appear in a clearing file, but may appear in a settlement report while skipping the clearing step.
| Flow | Pre-Authorization | Final Authorization |
|---|---|---|
| Use case | Reservations, travel/transit, delayed fulfillment | Regular purchases |
| Your action during real-time authorization | Hold balance | Deduct balance |
| In clearing file | Will be cleared separately, either in full or in multiple partials | Usually not present in a clearing file |
Is your system not able to hold balances? Open Fabric has a feature that converts pre-authorizations into final authorizations and refunds a payment if the authorization expires. Reach out to learn more.
Choose your Open Fabric integration
Open Fabric offers two ways to integrate for payment processing:
Ledger APIs
Open Fabric converts all payment requests from the network into ledger operations (e.g. credit, debit, or hold on your customer's account balance).
All relevant operations are sent to you via API—you do not need to process any clearing batch files.
Authorization and Clearing
Open Fabric sends you real-time authorization requests requiring your approval, plus clearing files in batches that include offline actions (e.g. refunds, expiry).
We follow the flow of the card networks combined use clear modern API calls and an easy-to-consume clearing file.