Running more than one payment gateway

Nobody sets out to run three payment gateways.

You start with one, because one is simple. Then a customer emails asking why they cannot pay by online banking. Then instalments start appearing at checkout on the sites you compete with. Then you open a counter and discover the wallet everybody already has is the quickest way to take RM12.

Each addition is individually correct. Collectively they produce a finance function nobody designed.

Why the drift happens

Malaysian buyers do not share one payment habit, and the differences are not preferences you can talk them out of.

Someone spending RM900 wants their own bank's screen, which means FPX and typically Billplz. Someone spending RM25 wants the wallet already in their pocket, which is GrabPay or a peer. Someone buying from outside Malaysia needs cards, which is Stripe or equivalent. Someone hesitating over a large basket converts on instalments, which is Atome. And a slice of your traffic arrives through ShopBack, where the cashback that won the customer is a cost that shows up on a settlement rather than in your marketing budget.

Refuse to support one of these and you are not simplifying your operations. You are declining a group of customers, quietly, at checkout.

What it actually costs you

The per-transaction rates are not the interesting part. Three other costs are.

Three reconciliation formats. Each provider reports differently: different column names, different treatment of refunds, different settlement calendars. Whoever reconciles has to hold three mental models rather than one.

Three settlement clocks. Money for the same trading day arrives on three schedules. Cash forecasting stops being a single calculation.

No single answer to "what did we take". The question requires opening three portals and adding up, which is exactly the kind of task that gets done monthly instead of weekly, and approximately instead of exactly.

Notice that none of these is a payments problem. They are all reporting problems produced by a payments decision.

The wrong fix

The tempting response is to consolidate — pick one provider, drop the others, accept the lost conversion in exchange for a simpler month-end.

That trades revenue for administrative convenience, which is almost always the wrong direction. The customers who wanted FPX do not switch to cards because your reconciliation is easier. They buy somewhere else.

The second tempting response is to keep all three and reconcile once a quarter, on the grounds that it is too much work to do more often. This works until something goes wrong, at which point you are investigating a three-month-old discrepancy across three providers with a memory of events that has faded.

The actual fix

Stop treating gateways as separate financial worlds and start treating them as separate sources feeding one set of orders.

An order does not care which gateway took the money. It should carry the payment, the settlement it arrived in, the fee deducted and any later reversal, regardless of which provider was involved. Once that is true, the number of gateways stops being an operational variable. Adding a fourth is a connection, not a project.

That is the reasoning behind reconciling against whichever gateways you actually run rather than requiring a particular one. Your payment mix should be decided by what converts customers. The reporting should absorb whatever that produces.

What to watch as you add them

Order references passed through. Whatever a provider offers for carrying your order reference into their settlement data, use it. It is the difference between matching by reference and matching by amount-and-timing, and it costs nothing to set up at the start.

Refund behaviour. Whether processing fees return on a refund differs by provider. Three gateways may mean three answers, and assuming a single rule across them produces small, permanent errors.

Settlement timing against your cash cycle. Not for its own sake, but because a supplier payment run on a day when one gateway has settled and two have not is a cash-flow surprise created by an administrative detail.

Which one is actually earning. Once fees are attached to orders, you can see the total cost of each payment method against the revenue it brought. Occasionally a payment method turns out to be carrying a cost that outweighs the conversion it wins — but you can only make that judgement with the numbers in front of you, and it is a commercial call rather than an automatic one.

The practical difficulty when both providers pay into the same account is that bank narration rarely identifies which is which, so the separation has to happen before any matching starts — see reconciling two gateways into one bank account.

Common questions

How many gateways is too many?

There is no number. The question is whether each one earns its place by bringing customers who would not otherwise convert, and whether adding it created work that scales with your volume. If the reconciliation is automated, the answer to "should we add another" is a commercial question. If it is manual, every addition is also a hiring decision.

Should I show every payment option at checkout?

Showing too many can slow a customer down, so it is a conversion question worth testing rather than a reconciliation one. Supporting a method and displaying it prominently are different decisions.

How do I compare the true cost of each gateway?

Attach every fee, refund adjustment and chargeback to the orders they came from, then total by payment method. The headline rate is only part of it — a method with a low rate and a high dispute frequency can cost more than one with a higher rate.

Does using several gateways complicate my accounts?

It adds settlement streams, not complexity of principle. Each still resolves to gross sales, fees and net settlement. The complication is entirely in whether something is joining those streams back to your orders, or whether a person is doing it three times over.

Let the customers choose

The payment methods you support should be settled by what your buyers reach for, and by nothing else.

The reason that is hard to hold to is that every addition lands on somebody at month-end. Fix that, and the question stops being how many gateways you can afford to reconcile, and goes back to being how many customers you would like to be able to serve.