What does a payment gateway do?
A payment gateway is the software connection between a merchant's payment experience and the providers that process the transaction. For an online card payment, it can collect or receive payment details, protect them in transit, format an authorization request, send it toward the processor or merchant acquirer, and return the issuer's approval or decline to the merchant.
The gateway moves payment data and messages; it does not itself move funds between bank accounts. Authorization is also not final settlement. A gateway may support later actions such as capture, void, refund, and status checks, but the exact responsibilities depend on the provider and integration.
Payment gateway vs processor vs acquirer
These roles are often bundled commercially, but they describe different jobs:
- Payment gateway: the merchant-facing software interface that securely transmits payment requests and responses.
- Payment processor: the service that handles transaction messages on the merchant's behalf and connects them to acquiring and network infrastructure.
- Merchant acquirer: the regulated institution on the merchant side that sponsors acceptance into the card networks and carries merchant underwriting and settlement responsibilities.
PCI Security Standards Council terminology notes that “payment gateway,” “payment processor,” and “payment service provider” are sometimes used interchangeably. Fintech builders should therefore verify the actual contractual, technical, and operational scope behind a provider's label.
What fintech builders should evaluate
- Integration and data flow. Map where payment details enter, which systems can access them, and how tokens and provider references map to the internal transaction record. Tokenization can reduce direct exposure to card numbers, but the integration design still determines PCI scope.
- Transaction lifecycle. Confirm support for authorization, capture, partial capture, voids, refunds, disputes, idempotency, and status recovery after timeouts. Do not treat a missing response as proof that a request failed.
- Routing and portability. Understand whether the gateway connects to one processor or acquirer or can support multiple providers, payment methods, currencies, and markets without changing the checkout contract.
- Operations and evidence. Preserve raw response codes, timestamps, gateway and processor identifiers, webhook history, and settlement references so support and finance teams can investigate failures and reconcile outcomes.
Common pitfalls
- Treating gateway approval as completed payment. An authorization can later expire, be reversed, fail to clear, or settle for a different amount.
- Assuming outsourcing removes PCI responsibility. PCI SSC says merchants that outsource all payment processing still need to validate their own compliance and oversee the provider's compliance and shared responsibilities.
- Ignoring ambiguous outcomes. Network timeouts can leave the merchant unsure whether the request was processed. Idempotency keys and status checks help prevent duplicate charges.
- Choosing only for checkout speed. Reliability, reporting, fraud controls, supported transaction states, data portability, and processor or acquirer dependencies all affect day-two operations.
Primary sources