Payment gateway
What is a payment gateway?
Payment gateway is the software layer that collects payment details at checkout, encrypts them, and passes them to the systems that actually move the money. It sits between a merchant's checkout and the , acquiring bank, and that carry out and .
A merchant's website and the card rails don't speak the same language. The gateway translates between them: it takes a browser-side submission and turns it into a properly formatted authorization request, then turns the bank's response back into something the checkout can act on. One gateway integration gives a business access to card payments, , and local alternative payment options without wiring up each bank separately.
Gateway and payment processor are often used interchangeably, but they aren't the same component. The gateway captures and transmits the data; the processor moves the transaction through the card networks to the and back. Many providers sell both together, which is why the distinction blurs in practice.
Key facts
- Also known as: gateway
- Sits between: the merchant's checkout and the payment processor or
- Core jobs: data capture, , , transaction routing, response handling
- Payment types handled: cards, digital wallets, and local payment methods, depending on the provider's coverage
- Security role: keeps raw card numbers out of the merchant's own systems, which narrows scope
- Not the same as: payment processor
How it works
- Capture. The submits card or wallet details through a payment form or hosted served by the gateway rather than by the merchant's own server.
- Encrypt and tokenize. The gateway encrypts the payment data in transit and replaces the card number with a token, so the merchant stores a reference instead of the real credentials.
- Route. The gateway formats the request and sends it to the payment processor or acquiring bank connected to the .
- Authorize. The processor passes the request through the card network to the issuing bank, which approves or declines it based on funds, card status, and its own risk checks.
- Return the response. The approval or decline code travels back through the same path. The gateway hands the checkout a result it can display in a second or two.
- Capture and settle. Approved authorizations are , batched, and settled, moving funds from the issuing bank to the merchant's account.
Why it matters
- The gateway defines which payment methods can appear at checkout at all. A market where most shoppers pay by local bank transfer is unreachable if the gateway doesn't support that method.
- Gateway availability is transaction availability. If the gateway times out, the sale fails even when the issuing bank would have approved it.
- Tokenization at the gateway keeps raw card numbers out of the merchant's environment, which reduces the systems that fall inside PCI compliance scope.
- The response the gateway returns carries the , which is what determines whether a failed payment is worth retrying or is a hard stop.
Common issues
- Downtime and timeouts. A gateway outage blocks every transaction behind it, and requests that time out mid-flight can leave the checkout and the bank with different views of what happened.
- Declines attributed to the gateway. The issuing bank makes the approve or decline decision. The gateway relays it, so a spike in declines is usually an issuer, risk-rule, or rather than a gateway fault.
- Coverage gaps. Provider method and currency coverage varies by market, and a gateway that performs well in one region may lack the local methods that convert in another.
- Token portability. Tokens issued by one gateway generally can't be read by another, so moving providers requires a token migration before stored-credential and recurring charges keep working.
