What is Payment Gateway?
Definition
A payment gateway is the service that securely captures card and similar payments on a website or app, routes them to banks and card networks, and reports the result back to the merchant. Card data collection, encrypted transmission, authorisation, voids and refunds happen in this layer, and the integration model chosen largely determines the merchant's security burden and PCI DSS scope.
Also known as: payment service provider, PSP, online payment gateway, card payment gateway, virtual POS
What happens behind the Pay button
When a shopper pays, several parties exchange messages within seconds: the merchant, the gateway, the merchant's acquiring bank, the card network and the bank that issued the card. A card payment usually involves three distinct operations:
- Authorisation: the issuer approves the amount and places a hold on the card's available balance.
- Capture: the merchant confirms it will collect the authorised amount. Many shops authorise and capture in one call; businesses that charge on dispatch keep the two apart.
- Settlement: funds, minus fees, reach the merchant's account on the agreed schedule.
Voids and refunds differ as well. Cancelling before the daily batch closes usually just releases the authorisation; after that, the money goes back to the card as a separate refund transaction.
The integration model sets your security burden
| Model | Where card data travels | Merchant burden |
|---|---|---|
| Hosted payment page (redirect) | Only the provider's page | Lowest |
| Embedded fields (iframe / hosted fields) | The provider's iframe inside the merchant's page | Low, but scripts on the payment page now matter |
| Direct API | Through the merchant's servers | Highest; every system touching card data is in scope |
If card numbers never reach the merchant's servers, the PCI DSS compliance effort shrinks dramatically. A direct API integration gives full design control, but it also makes the merchant responsible for encrypting card data, keeping it out of logs and locking down access.
Tokenisation: never holding the card number
With tokenisation the card number stays in the provider's vault, and the merchant receives a token that only means something to that provider. One-click payments with saved cards, subscription renewals and refunds all run on the token. A leaked token cannot be used as a card anywhere else. The downside is portability: moving saved cards to a new provider is a migration project that both providers have to support.
Confirm on the server, not in the browser
After payment the shopper's browser is redirected to the merchant's success page, but that redirect proves nothing on its own. The tab may close, the connection may drop, or someone may simply type the URL. A reliable flow updates the order either by querying the provider's API from the server or by handling the provider's webhook. Verify the webhook's HMAC signature, and since the same notification can arrive more than once, make the handler idempotent:
if (!signatureValid(request)) return 401
if (order.status === "paid") return 200 // duplicate delivery
markOrderPaid(order.id, request.transactionId)
return 200Choosing a provider
Technical and commercial criteria belong in the same comparison:
- supported payment methods and, in markets such as Turkey, instalment options;
- how 3D Secure behaves on mobile and inside apps;
- fees, settlement timing and refund costs;
- quality of API documentation, sandbox and webhook support;
- support for saved cards, subscriptions and marketplace or split payments.
In Turkey, merchants typically either sign a virtual POS agreement directly with a bank or use a licensed payment institution that connects to several banks; such institutions are licensed by the Central Bank of the Republic of Turkey under Law No. 6493. The shopper-facing side of all this is covered under checkout.