Issuer vs acquirer: same swipe, different ledger
Two fintechs touch the same card payment. Their books look nothing alike.
By Solomon Ajayi · Free to read, no signup
A user with a Verve card from FintechA swipes ₦10,000 at a merchant whose payment processor is FintechB. FintechA is the ISSUER (the card belongs to them). FintechB is the ACQUIRER (the merchant is their customer). One swipe; two completely different ledger flows. The issuer charges the user, pays the acquirer through the scheme. The acquirer collects from the scheme, pays the merchant after deducting fees. This lesson posts BOTH sides of the same ₦10,000 transaction so you can see the symmetry, and why a single fintech that does both (a Stripe, a Paystack) has to keep its issuer ledger strictly walled off from its acquirer ledger.
One card swipe touches two fintechs that have never met, and their books look nothing alike. The issuer owns the card and tracks what the cardholder owes. The acquirer owns the merchant relationship and tracks what the merchant is owed. Same ₦10,000, two entirely separate ledgers, with the card scheme sitting in the middle as the settlement conduit and taking its cut in both directions.
On the issuer side, the cardholder owes you the full amount, you will owe the scheme that amount net of interchange, and the interchange itself is income you earn for being the issuer. On the acquirer side, the scheme will pay you the amount already net of interchange, you owe the merchant that amount minus your merchant discount rate, and the spread you keep is your revenue. The two flows mirror each other across the scheme, which is why the same purchase appears on both sets of books.
Platforms like Stripe and Paystack run both roles at scale, which creates a trap. The same value of GMV can legitimately appear on both your issuer books and your acquirer books, and if you let those two trees touch you will double-count revenue or, worse, net them against each other. Netting an issuer position against an acquirer position is a regulatory red flag precisely because it hides exposure. The chart of accounts has to wall the two sides off into strictly separate trees.
Worked example, step by step
ISSUER side: cardholder owes ₦10,000; scheme is owed ₦9,800 (₦200 interchange to you)
From FintechA's books. The user's account is debited ₦10,000 (it shows up on their statement). The scheme (Verve, Mastercard, Visa) is the conduit: you owe them the full ₦10,000 they'll pay the acquirer, but they pay YOU ₦200 in interchange for being the issuer. Net you owe the scheme ₦9,800.
| Account | Debit | Credit |
|---|---|---|
| Issuer: Cardholder Receivable (1560) | ₦10,000.00 | |
| Issuer: Owed to Scheme (2300) | ₦9,800.00 | |
| Issuer: Interchange Earned (4400) | ₦200.00 |
Issuer: Cardholder Receivable UP ₦10,000 (asset, debit, the user owes you). Issuer: Owed to Scheme UP ₦9,800 (liability, credit, you'll pay this in tomorrow's settlement). Issuer: Interchange Earned UP ₦200 (income, credit, your cut). Three lines, balanced: 10,000 = 9,800 + 200.
ACQUIRER side: scheme owes you ₦9,800; you owe the merchant ₦9,650 (₦150 MDR)
From FintechB's books. The scheme will pay you ₦9,800 (the user's ₦10,000 minus the issuer's ₦200 interchange). You'll pay the merchant ₦9,650 (after taking ₦150 as your MDR, Merchant Discount Rate, your acquirer fee). Your net revenue from this swipe is ₦150 minus the network/scheme fees you owe on top of the interchange. Simplified here.
| Account | Debit | Credit |
|---|---|---|
| Acquirer: Scheme Receivable (1570) | ₦9,800.00 | |
| Acquirer: Merchant Payable (2400) | ₦9,650.00 | |
| Acquirer: Interchange Paid (5600) | ₦150.00 |
Acquirer: Scheme Receivable UP ₦9,800 (asset, debit, scheme will pay you). Acquirer: Merchant Payable UP ₦9,650 (liability, credit, you owe the merchant net of your fee). Acquirer: Interchange Paid UP ₦200, wait, that's not on this entry. Re-think. Acquirer is GIVEN ₦9,800 (already net of interchange) and KEEPS ₦150 (MDR). So the entry is: Scheme Receivable ₦9,800 debit, Merchant Payable ₦9,650 credit, Acquirer Revenue (the ₦150 you keep) credited. Recasting:
Takeaway
Issuer accounting tracks what the CARDHOLDER owes; acquirer accounting tracks what the MERCHANT is owed. The scheme (Visa, Mastercard, Verve, RuPay) sits in between as the settlement conduit, taking its cut both directions. A platform that's BOTH an issuer (cards for users) AND an acquirer (processing for merchants) has to keep these accounts in strictly separate trees in the chart of accounts, same ₦10,000 of GMV can appear on BOTH sides of your own books, and netting them is a regulatory red flag. Stripe, Paystack, Adyen are issuer + acquirer at scale; their reporting separates by entity precisely for this reason.
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.