A customer swipes a card at a POS terminal or confirms a purchase on an online store's payment gateway. As far as they are concerned, the purchase is done, but the system is still waiting for one more step: the merchant has to finalize the purchase. The gap is usually short, yet even in that short window the connection can drop, the customer can change their mind, or the store's system can return an error.
In Dara, the Credit Card module handles this gap with a two-phase purchase. Both phases are recorded on the Financial Core, and at no point does the customer's credit go up or down without a voucher.
Phase one: purchase
Each card type is linked to an account heading in the Financial Core, and each card is issued to a counterparty. When a purchase request comes in, the system reads the customer's available credit from the Financial Core. If there is enough credit, three things happen together:
- A pending hold for the purchase amount is placed on the customer's credit, so the available credit drops immediately.
- A provisional voucher for the purchase is posted to the Financial Core.
- The transaction is saved with the status “Pending” and an expiry time.
This phase returns the transaction ID and its expiry time. The merchant uses that ID to finalize the purchase in the next phase.
Phase two: confirmation
When the merchant confirms the purchase, the provisional voucher becomes final and the transaction moves to the “Settled” status. From that moment on, the purchase is part of the card's billing-cycle statement and is counted in the merchant settlement.
When confirmation never arrives
If the system waited indefinitely for confirmation, the customer's credit would stay tied up in a purchase that never happened, and on their next purchase they would see an “Insufficient credit” message without knowing why.
In Dara, an expiry service checks pending transactions at short intervals. A transaction whose expiry time has passed is marked expired, its provisional voucher is rejected, the pending hold is removed and the credit is returned to the customer. Nobody has to do any of this by hand.
The merchant confirmation window is set in the system settings. A short window frees up the customer's credit sooner, while a longer one gives more time to merchants that send their confirmation with some delay. The right choice depends on the type of merchants and the purchase channel, and it is decided separately when each network is set up.
Purchase reversals
If a purchase is reversed after confirmation, a reversing voucher is posted and the amount is returned to the customer's credit. The original transaction and the reversal both remain in the history, each with its own voucher.
Duplicate requests
In payments, a duplicated request is more dangerous than a dropped one. Every purchase in Dara has an idempotency key: for POS purchases it is the payment service provider's transaction ID, and for network purchases it is the hub transaction ID. If the same request arrives again, the original result is returned and no second purchase is created.
Network purchases
Under shared acceptance, several card issuers and several acceptance networks are connected through a hub. Network purchases follow the same two phases: the purchase request, confirmation, status inquiry and reversal are all carried out against the hub transaction ID. That way, the issuer and the acceptance network share a single answer on the status of each purchase.
Transaction statuses
Every purchase transaction has one of these statuses: pending, settled, failed, reversed or expired. These statuses correspond to the status of the matching voucher in the Financial Core: a pending transaction has a provisional voucher, a settled transaction a final voucher, and a reversed transaction a reversing voucher. Voucher and transaction statuses are reconciled periodically, so that any mismatch between them comes to light before the period is closed.
One-time passwords and QR purchases
Online purchases, and any purchase that carries higher risk, get an extra confirmation step: a one-time password sent by SMS. The code is valid only briefly, each customer can have only one active code at a time, and the number of failed attempts is limited. In a QR purchase, the customer scans the merchant's code, and purchase and confirmation happen in a single step.
What this means for customers, merchants and finance teams
- Customers always see their correct available credit.
- Merchants are not credited in settlement for a purchase until they have confirmed it.
- The finance department has a voucher for every purchase. Its status matches the transaction status and is checked in the periodic reconciliation.
Fantap, Dara's sister company, has built its acceptance network and white-label cards on this same mechanism.
- #Credit_card
- #Merchant
- #Settlement
- #Provisional_voucher
