The gateway question is rarely about fees. It is about who your customers are, what currency they pay in, and what happens on the day a payment succeeds but your system never hears about it.
Every project that takes money runs into this question, and most people answer it by comparing percentage fees. That is the least interesting difference between them. ## Start with who is paying If your customers are Nigerian, paying in naira, with Nigerian cards and bank transfers, you want a Nigerian gateway. Paystack and Flutterwave both do this well, both support cards, bank transfer and USSD, and both settle to a Nigerian account. If you are billing internationally, in dollars, from customers with foreign cards, Stripe is the straightforward answer and the one your overseas customers already trust. If you are collecting on behalf of a school, a government body or anything with institutional reporting, Remita is often not a choice at all. It is a requirement handed to you. Plenty of projects need two. A school that takes fees from local parents and donations from alumni abroad is a two-gateway project, and that is fine. ## The fee difference is smaller than the failure difference A fraction of a percent matters when you process a lot. What matters more at any volume is how often a payment fails for a reason your customer does not understand, and what you can do when it does. Ask instead: what does a failed card show the customer? How quickly can I see a specific transaction? Can I refund without emailing support? Those answers decide how much of your week goes on payment problems. ## Bank transfer is not a fallback, it is a primary method Outside tech circles, a large share of Nigerian customers prefer transfers, and some will abandon a card form rather than type their details. Treat transfer as a first-class option: show the account, generate a reference, and give someone a way to confirm it. The work here is reconciliation. A transfer that lands with no reference is money you cannot match to an order, which means a human matching it by hand. Build the reference in from the start. ## Pay on delivery is a business decision, not a technical one It converts well and it loses money to failed deliveries. If you offer it, the system has to track the cash from the rider back to the till, otherwise you have a leak nobody can see. ## The part everyone skips: webhooks A customer pays, the gateway confirms, your system hears about it. That last step fails sometimes. The network drops, your server restarts, the request times out. If your system only learns about payment from the customer's browser redirecting back, you will have paid-but-unrecorded orders. Verify every payment server-side against the gateway's API, and handle the webhook arriving twice for the same payment without creating two orders. That one detail separates systems that need a human babysitting them from ones that do not. ## What I would do on a new project Nigerian customers paying in naira: Paystack or Flutterwave, bank transfer enabled, references generated per order, webhooks verified server-side. International customers: Stripe, and keep the local gateway if you also sell at home. Institutional collection: whatever the institution requires, and budget more time than you think for reconciliation. Then make the thing you can actually control excellent: a checkout that does not ask for anything it does not need, a clear message when something fails, and a receipt that arrives without being asked for.