Payment gateway

A payment gateway is the service that collects money for you when somebody buys on your website. It takes the payment details, checks with the bank or the wallet that the money is there, approves or refuses the transaction in a couple of seconds, and then pays out to your account on its own schedule. It sits between your store and the banking system so that you never have to touch either.

In short

• It takes the payment, checks it, and pays out to you later.
• The money arrives days after the sale, not at the moment of it.
• Card details go to the provider, never onto your own server.
• Cash on delivery sits outside it and has to be reconciled separately.

What happens in those two seconds

The delay between somebody pressing pay and seeing a confirmation is doing more work than it appears.

The gateway encrypts what was entered and sends it on. The bank or wallet checks that the account exists, that the money is available, and that the transaction does not look like fraud. An answer comes back, the gateway tells your store, and your store shows a confirmation or an error. The customer sees a spinner. Four parties have spoken to each other.

This matters because each of those parties can refuse, and the reason often arrives at your store as a single unhelpful word. A payment that failed at the bank and one that failed a fraud check look identical from the outside.

The part that surprises people

The sale and the money are separate events, separated by days.

Gateways hold funds for a settlement period before paying out. The reason is sensible: refunds, chargebacks and fraud all surface after the fact, and the provider would rather hold the money than chase it. New accounts frequently start on a longer hold than established ones, and holds can be extended without much notice if disputes rise.

A business that planned its buying around same-day money finds this out in its first busy week. It is worth knowing the payout schedule before launch rather than after, because it changes how much working capital the store needs.

What you should never handle

The strongest argument for using a gateway at all is that it keeps card details away from you.

• The card is entered on their side, either on a page they host or in a field they control that only looks like part of your site.
• Your server never stores the number. What you keep is a reference, which is useless to anybody who steals it.
• Most of the compliance burden sits with them, which is the difference between a form on your site and a regulated obligation of your own.
• Your exposure shrinks, and it does not vanish. A page that has been tampered with can still be used to capture cards around the provider’s field, which is why the rules now expect the payment page itself to be watched for changes.

Any arrangement where card numbers pass through your own server should be refused, whatever it saves. The exposure is far larger than the saving. Keeping the checkout page free of scripts nobody can account for is the other half of the same job.

Choosing one in the Philippines

The decision is less about the provider and more about what your buyers already use, which is a different question than it would be in Europe or the United States.

Wallets do most of the work here. GCash and Maya are how a large share of buyers expect to pay, and a checkout that offers cards alone has quietly excluded them. Bank transfer still matters for larger orders. Cards matter for a smaller group and for anybody buying from abroad.

Then there is cash on delivery, which is not a gateway matter at all. The courier collects and remits on their own schedule, so a store offering both ends up with two separate flows of money arriving at different times through different channels. Reconciling those is ordinary work, and it is work nobody warns you about.

What it costs you in practice

Every gateway takes a share of each transaction, and the share differs by method.

That is worth knowing for two reasons, and neither is about hunting for the cheapest provider. The first is that your margins differ by payment method, so a product that works on one method may not on another. The second is that refunds frequently do not return the full deduction, which means a store with high returns is losing a little on every reversed sale.

Read the schedule for each method before you enable it. The figures are published and the differences between methods are usually larger than the differences between providers.

Where it goes wrong

• Only one method offered, so buyers who use another simply leave. It sits among the causes of cart abandonment that a store can actually fix, alongside surprise delivery costs and forced accounts.
• Methods hidden until the last step. Somebody who cannot see their wallet on the product page assumes it is not accepted.
• Nobody reconciling. Gateway payouts, courier remittances and store orders drift apart, and the gap is only found at the end of the year.
• One provider and no alternative, which becomes a real problem the week an account is frozen for review.
• Test mode left on, so the store takes orders and collects nothing. It happens, and usually on a launch day.

How it fits with the rest of the store

The gateway is one piece of a shop, and it is rarely the piece that decides whether the shop works.

A store loses far more orders to a confusing checkout, a missing delivery cost or a checkout that fights the phone than it ever loses to the choice of provider. The gateway matters enormously when it is missing a method your buyers use, and hardly at all once it covers them. The wider picture, including catalogue, delivery and what happens after the order, is on the e-commerce entry.