The customer reached the checkout. From here you have about three seconds and one attempt. If something goes wrong in those seconds, they will not write to support. They will close the tab.
The payment gateway is the part that works during those three seconds. Here is what happens inside, where the money leaks, and what to look at when choosing one.
Contents
- What a payment gateway is
- What happens in those three seconds
- Where the money leaks
- Cascading and local acquiring
- Hosted page or API
- What the price is made of
- 3-D Secure: protection and loss
- Gateway, merchant account, IBAN and wallet
- Common mistakes when choosing
- What to check before connecting
- Payment methods besides cards
- How to tell the gateway is the problem
- Short answers
- Where to start
What a payment gateway is
A gateway moves payment data between the customer, your site and the banks. It encrypts the card, sends the authorisation request and returns the answer.
It gets confused with processing and with a merchant account. The difference is simple. The gateway is the channel. Processing executes the transaction. The merchant account is where the money lands.
You need all three. They do different jobs, and you choose them on different criteria.
What happens in those three seconds
- The customer presses Pay on your page
- The gateway encrypts the card data and passes it on
- The request reaches the acquirer, then the card scheme
- The issuing bank checks funds, limits and risk
- 3-D Secure steps in where required
- The answer comes back: approved, declined or verification needed
Any delay along that path costs conversion. So does any extra screen.
Where the money leaks
Declines fall into two groups, and they are fixed in different ways.
Issuer declines. Insufficient funds, a limit on online payments, a suspicion of fraud. The gateway has little say here.
Infrastructure declines. The wrong acquirer, a country the bank does not recognise, an incorrect MCC, a routing failure. This is the gateway’s territory, and this is the revenue you can actually win back.
The second group is invisible without decline-code reporting. If your provider does not show it, you will not know what you are losing.
Cascading and local acquiring
The same card gets approved by one acquirer and declined by another. The bank looks at the acquirer’s country, the merchant category and the history.
Cascading means retrying through a second acquirer after the first declines. The customer never sees the error.
Local acquiring means taking the payment in the customer’s own country. The transaction stops looking foreign to the bank, and approvals rise noticeably.
Hosted page or API
A hosted page sends the customer to the provider’s payment screen. It connects in a day, card data never touches you, and the provider carries the PCI DSS burden.
With the API, the payment form lives on your site. It looks tidier, but part of the security obligation moves to you.
At launch, hosted is the sensible answer. Moving to the API is a conversation for when volume justifies the extra responsibility.
What the price is made of
The rate has several parts: the scheme’s interchange, the scheme fee, the acquirer’s margin and the provider’s margin. Only the last one is negotiable.
Then come the items that are easy to miss. Setup fee, monthly minimum, conversion spread, refund fee, chargeback fee.
Below 10 000 euro a month the monthly minimum often costs more than the percentage. Ask for the breakdown rather than the headline number.
3-D Secure: protection and loss
3-D Secure shifts liability for a fraudulent transaction to the issuing bank. That is a strong argument, and for European cards the check is mandatory.
But every extra screen costs you some customers. One forgets the password, one never receives the SMS, one simply closes the window.
The current protocol can skip the step for trusted transactions. Ask your provider whether that is supported and how it is configured.
Gateway, merchant account, IBAN and wallet
- Gateway — takes the payment on your site and passes it on
- Merchant account — where the money arrives from the acquirer
- Business IBAN — the company account you pay suppliers from
- Wallet — needed when customer money has to live inside your system
Most online shops need the first three. A wallet appears once your users have balances of their own.
Common mistakes when choosing
Comparing the rate alone. Approval rates and settlement times move the money more than a tenth of a percent ever will.
Taking a single acquirer. One bank is one point of failure. If it drops you, your payments stop entirely.
Ignoring reporting. Without decline codes you cannot tell why payments fail, and you will fix the wrong thing.
Forgetting refunds. They happen less often than payments, and that usually becomes clear at an inconvenient moment.
What to check before connecting
- How many acquirers are available, and whether any are local to your markets
- Whether cascading is supported, and on what terms
- What payment methods exist besides cards
- What the reporting looks like — are decline codes visible
- Settlement timing and whether a reserve applies
- Whether there is a sandbox and public API documentation
Payment methods besides cards
Cards do not work the same way everywhere. In some countries almost everyone pays by card; in others a bank transfer or a local wallet is the norm.
- Bank transfers. The fewest disputes: the customer pushes the payment and cannot reverse it the way a card payment can be reversed
- Local methods. Different in every country, and their presence lifts the share of completed payments noticeably
- Wallets. Apple Pay and Google Pay cut the path down to one tap
- Crypto. No chargebacks, but source-of-funds checks still apply
Start with cards plus one or two methods for your main market. Switching everything on at once is expensive and pointless.
How to tell the gateway is the problem
Not by feel. By three numbers.
Approval rate. Read it per country and per method. A drop in one country points at the acquirer, not at your product.
Decline codes. If technical codes outnumber «insufficient funds», the problem sits in the infrastructure.
Abandoned payments. The customer reached the form and did not finish. Usually that is an extra verification step or a slow page.
Short answers
How is a gateway different from processing?
The gateway moves the
data, processing executes the transaction. They usually come in one contract, but they
are different functions.
Do I need a separate merchant account?
Yes. The gateway only
carries the payment; the money has to arrive somewhere.
How long does connecting take?
The technical part starts at a day
with a hosted page. Document review takes longer, and that is what sets the timeline.
Can I change gateway later?
You can, but migrating subscriptions
and stored cards is a project of its own. Worth asking about before you connect, not
after.
Where to start
Describe how your customers pay: countries, amounts, cards or transfers. That decides both the set of acquirers and the way you connect.
You can open an account on the merchant accounts page; the technical side is under payment processing.
Read next
- Ecommerce Payment Gateway: How to Choose One That Pays Off
- Merchant White Label Payment Solution for Global Businesses
- Marketplace Payment Solution: Six Things to Require Before You Sign
- Payment System for Ecommerce: What It Is Made Of and Who Decides What
- Business Merchant Account: The Financial Infrastructure Built for Online Revenue

