Build or buy: taking payments online

"Build or buy" is the wrong question about card payments, because nobody small builds the part that matters. What you choose is who holds the risk when a payment goes wrong, and who does the matching when the money lands. Buy an arrangement and someone else carries the credit risk while you keep the reconciliation; build the layer around it and you still buy the arrangement, having deliberately made the surrounding work yours. The answer flips with volume and disputes: at ten orders a day that work is a spreadsheet; at two hundred, a system.

What are the four layers, and which one do you never touch?

The gateway is what your checkout calls: it collects the card details, returns an authorisation and reports the outcome. The acquirer holds your merchant account and takes the credit risk of you not delivering. The processor routes the authorisation to the issuing bank and back. Settlement is the money moving: the batch, the fees deducted, the statement you reconcile.

A small business touches the gateway, signs with an acquirer, and never meets the processor or the card scheme. Those are a licensed, contractual world: an integration does not create a merchant account, and no amount of code makes you a member of a card network.

Why does "build" rarely mean building the payments?

Because the interesting problem is never the authorisation call. It is what the call leaves behind:

• A refund that must be partial, repeated, and reflected in the order's state.
• A retry that must not charge twice a customer whose connection dropped.
• A settlement file whose total does not match the day's orders, and the hour spent finding out why.
• A dispute arriving weeks later, needing evidence from your own records.

A gateway sells an authorisation API. The state machine on the order, the refund rules, the matching and the evidence are yours whichever way you go. Buying removes the acquiring problem, not the operational one.

Who holds the risk when something goes wrong?

Split it honestly. The acquirer carries credit risk: take the money and never deliver, and the loss lands there first. You carry operational risk: a double charge, a refund that never reached the card, a settlement short by the value of one order, a notification telling a customer they paid when they did not.

Fraud sits between the two. The acquirer pushes risk back to you through chargebacks, and the evidence you can produce decides the outcome. A build that does not store what was ordered, when it shipped and to which address has no evidence, so disputes are unwinnable by design.

Who reconciles, and against what?

You do, always, in both directions. Every settlement has to be matched to orders: gross, fees, refunds, and the net that reached the bank. The gateway supplies a file or an API; matching it is the merchant's job.

That matching is where the real cost of building appears, because it is easy to build the checkout and forget the month-end. A system that cannot answer "which orders are in this settlement" turns every discrepancy into an argument with the acquirer and a hunt through a spreadsheet.

The obligation does not move when you buy. What changes is whether the tooling arrives with the product.

What does cash on delivery change?

In Algeria most commerce settles in cash, and cash does not pass through a gateway at all. The courier collects, holds the money, remits on a schedule, deducts the delivery fee, and returns what was refused. Your system has to model three things a card integration never teaches: a remittance per courier per period, a return that costs money instead of refunding it, and an order whose payment state is "with the courier" for a week.

That is why a gateway is often the wrong first project. If most revenue is cash, the constraint is delivery and remittance, and a card checkout adds a second reconciliation to a business that has not finished the first. Build the cash ledger first; add the gateway when prepaid demand is real.

The decision that settles it

Question	Lean to buy	Lean to build
Order volume	a few a day, one person handles exceptions	enough that exceptions need a queue and an owner
Refunds	occasional, done by hand	routine, with rules and partial amounts
Disputes	rare, handled case by case	recurrent enough to need evidence on file
Failed settlement	absorbed quietly once	recurring, and must be detected the same day
What you do either way	match settlements, keep evidence	match settlements, keep evidence

How to decide, in order

1. Count orders, refunds, and the hours spent matching them now.
2. Write down who answers a customer who says "I paid and you say I did not".
3. Ask the acquirer what evidence wins a dispute, then check your order records contain it.
4. Model the settlement: which file arrives, when, and what fields it carries.
5. Decide the cash ledger before the card checkout if cash is still most of the revenue.
6. Then choose between an off-the-shelf integration and a custom layer, pricing the reconciliation in both.

Where this goes wrong

• Building a checkout and calling it a payment system. The authorisation is a week; the reconciliation is the project.
• No idempotency. A retried request becomes a second charge, and the refund costs more attention than the sale.
• Treating the settlement as a bank statement. It is a list of transactions with fees attached, matched line by line.
• Deciding on the transaction fee alone. The visible number is the rate; the reconciliation, disputes and failed settlements are the cost.
• Storing no evidence. A dispute you cannot answer is a loss you agreed to in advance.
• Two truths for one order. The shop says paid, the acquirer says pending, and nobody owns the difference.

When neither fits

If the business sells cash on delivery in small baskets, a card checkout is not the next project — the courier remittance is. If the buyer is a business ordering on account, the payment problem is credit control: an invoice, a due date and a person who chases it.

What this advice leaves out

No prices, no rates, and no legal claims. Which entity may acquire, what a merchant agreement requires, what must appear on a receipt and how long records are kept are questions for the provider and for your accountant — the rules are theirs to state, and they differ by country and by contract. This also says nothing about cross-border acceptance, currency conversion or marketplace splits, each of which reshapes the settlement.

We build the order record, the settlement matching and the cash ledger around whichever arrangement you sign. We resell no gateway and take no commission on the choice.

We start from the reconciliation, because a business that cannot match its own money has not yet bought a payment system.