Push vs pull payments
Who initiates the money movement decides who eats the chargeback.
By Solomon Ajayi · Free to read, no signup
Every payment rail is either a PULL (you tell the user's bank to send you money: cards, direct debit) or a PUSH (the user tells their bank to send you money: bank transfer, RTP, NIBSS Instant Pay). The ledger shape is similar, but the RISK shape is opposite. Pull rails settle T+1 or later and the issuer can claw the money back for 60+ days (chargeback). Push rails settle in seconds and money is final on receipt. This lesson posts the same ₦10,000 deposit on both rails and shows why your provisional / final / cleared liability accounting depends on which rail the money came in on.
Who pressed go on a payment decides who carries its risk. On a pull rail you reach into the user's bank and take the money: cards, direct debit. The issuer can later decide the pull was wrong and claw it back, sometimes for months. On a push rail the user pushes the money to you: a bank transfer, NIBSS, RTP. Once it lands it is final, because the sender's own bank already authorized and moved it. Same direction of money, opposite direction of risk.
That risk difference has to show up in the ledger, not just in a risk dashboard. Card money arrives provisional: you credit the user a wallet balance they can spend, but you book both the receivable and that wallet balance into provisional accounts, because the issuer might reverse the whole thing. When it settles a couple of days later, two transitions fire together: the provisional receivable becomes real bank cash, and the user's wallet moves from the provisional bucket to the cleared one. A push deposit skips all of that, one entry, straight to cleared.
Splitting provisional from cleared on both the asset and the liability side is what lets you size your exposure. The sum of the provisional wallet balances is exactly the money your users can spend today that an issuer could still pull back from you tomorrow. Collapse everything into one wallet account and that number disappears; you can no longer tell your risk team, or your sponsor bank, how much clawback you are carrying.
Worked example, step by step
PULL: ₦10,000 in via card (provisional)
User funds via card. The provider tells you 'we authorised ₦10,000 against the issuer.' The money is NOT in your bank yet, and the issuer can reverse the charge for the next 60-120 days. You credit the user's wallet so they can spend, but you book the user's claim against your PROVISIONAL pot and treat the receivable as provisional too.
| Account | Debit | Credit |
|---|---|---|
| Provisional Card Receivable (1250) | ₦10,000.00 | |
| User Wallet (Provisional) (2055) | ₦10,000.00 |
Provisional Card Receivable UP ₦10,000 (asset, debit). User Wallet (Provisional) UP ₦10,000 (liability, credit). The user sees their balance go up; the books mark it as 'not final yet.' This split is what lets your risk team show 'available-but-clawback-risk' separately.
PULL settles 2 days later: provisional → cleared
T+2. Provider settles to your bank account. The card-clawback window is largely past for THIS transaction (chargeback is still possible up to 120 days, but for ledger purposes we treat settled = cleared). Two entries fire in one transaction: the provisional receivable becomes real bank cash, and the user's wallet moves from provisional to cleared.
| Account | Debit | Credit |
|---|---|---|
| Bank Account (1200) | ₦10,000.00 | |
| User Wallet (Provisional) (2055) | ₦10,000.00 | |
| Provisional Card Receivable (1250) | ₦10,000.00 | |
| User Wallet (Cleared) (2050) | ₦10,000.00 |
Bank Account UP ₦10,000 (asset, debit). Provisional Card Receivable DOWN ₦10,000 (credit). User Wallet (Cleared) UP ₦10,000 (credit). User Wallet (Provisional) DOWN ₦10,000 (debit). Same user, same money, but the bucket they're in changed. Four lines because two transitions happen in sync.
PUSH: ₦10,000 in via NIBSS Instant Pay (cleared immediately)
Different user. They open their bank app and send ₦10,000 via NIBSS Instant Pay. Money is in your bank account within 30 seconds, irrevocable. No clawback window. No 'provisional' state.
| Account | Debit | Credit |
|---|---|---|
| Bank Account (1200) | ₦10,000.00 | |
| User Wallet (Cleared) (2050) | ₦10,000.00 |
Bank Account UP ₦10,000 (asset, debit). User Wallet (Cleared) UP ₦10,000 (liability, credit). Two lines, done. Compare to the pull rail: same final state in just one step, no transition, no risk-bucket gymnastics. This is why push rails are cheaper to run.
Takeaway
Pull rails (cards, direct debit) settle later and carry clawback risk; your books need a PROVISIONAL bucket for both the receivable and the user's wallet. Push rails (RTP, NIBSS, UPI, Pix, FedNow, ACH credit) settle in seconds and are final; one entry, cleared. Fintechs that treat all deposits the same way silently understate their clawback exposure. Your risk dashboard should report 'wallet balance (provisional)' and 'wallet balance (cleared)' as separate numbers, your sponsor bank's risk team will ask for both.
Practice this on a real ledger
Reading is half of it. Open this lesson in the lab to post the entries yourself against a real Postgres-backed double-entry ledger, with the validation on. Free, your sandbox is yours.