- Homepage /
- Blog /
- What Is A Payment Gateway And How Does It Work
What Is a Payment Gateway and How Does It Work?
Discover how payment gateways work, the differences between gateways and processors, and essential compliance requirements for online transactions.
A payment gateway is a software service that authorizes and transmits card or bank payment data between a merchant and the acquiring bank. It sits between the customer’s browser or point-of-sale terminal and the financial network that moves the money.
Think of it as a secure courier. The gateway takes encrypted payment data from the buyer, checks it with the card network, and returns an approval or a decline to the merchant. The whole exchange takes two to four seconds.
The gateway does not hold funds. It does not settle transactions. Its single job is to validate the payment instruction and pass it forward. A separate entity, the acquiring bank or payment processor, moves the money.
This distinction matters. Many practitioners conflate the gateway with the processor. They are different roles in the chain. The gateway is the door. The processor is the engine behind the door.
How Does a Payment Gateway Work?
The payment flow follows a fixed sequence. Each step depends on the one before it.
Step 1: The customer initiates payment.
The customer enters card details, selects a digital wallet, or taps a card at a terminal. The merchant’s website or terminal captures this data.
Step 2: The gateway encrypts the data.
The gateway encrypts the card number, expiry date, and CVV using TLS 1.2 or higher. It formats the data into the message standard that the card network requires (ISO 8583 for card networks, ISO 20022 for bank transfers).
Step 3: The gateway sends the authorization request.
The encrypted payload goes to the acquiring bank, which routes it to the card network (Visa, Mastercard, Amex, or a regional scheme).
Step 4: The card network queries the issuing bank.
The network forwards the request to the bank that issued the customer’s card. The issuing bank runs its checks: sufficient funds, card status, fraud rules, and 3-D Secure authentication if the transaction requires it.
Step 5: The issuing bank responds.
The issuing bank returns an authorization code (approved) or a decline code with a reason. This response travels back through the card network to the acquiring bank, then to the gateway.
Step 6: The gateway relays the result to the merchant.
The merchant’s website displays “payment approved” or “payment declined” to the customer. The merchant either fulfills the order or asks for a different payment method.
Step 7: Settlement occurs later.
Hours or one to two business days after authorization, the acquiring bank collects the approved funds from the issuing bank through the card network. The acquirer deposits the net amount (minus interchange and fees) into the merchant’s account.
The gateway participates in Steps 1 through 6. Settlement (Step 7) is a processor and bank function.
Payment Processing Systems: The Full Chain
A payment gateway is one component in a larger payment processing system. Understanding the full chain helps practitioners diagnose failures, negotiate contracts, and scope compliance work.
| Role | Function | Example |
| Customer | Initiates the payment | Cardholder, wallet user |
| Merchant | Sells the goods or service | E-commerce store, SaaS platform |
| Payment gateway | Encrypts and transmits the authorization request | Stripe, Adyen, Checkout.com, PayU |
| Acquiring bank | Holds the merchant account, routes the request | Wells Fargo, Barclays, HDFC |
| Card network / scheme | Connects acquirer to issuer, applies interchange rules | Visa, Mastercard, RuPay, UPI |
| Issuing bank | Verifies funds, approves or declines | The customer’s bank |
| Payment processor | Handles settlement, batch processing, and reporting | First Data (Fiserv), Worldpay, Razorpay |
Each link in this chain has its own obligations under card network rules and financial regulation. A breach at any point creates liability for the parties upstream and downstream.
The two message standards
Two international standards govern how payment data moves between these parties:
ISO 8583 governs card-based transactions. It defines the message format for authorization, capture, and reversal. Most card gateways still use ISO 8583 or its 2003 revision.
ISO 20022 governs bank-to-bank transfers, real-time payments, and cross-border transactions. The Federal Reserve migrated Fedwire to ISO 20022 in March 2023. The Eurosystem’s TARGET2 followed in November 2023. SWIFT is migrating its network to ISO 20022 through a coexistence period that ends in November 2025.
Practitioners who work in cross-border payments or corporate treasury must track the ISO 20022 migration. Legacy ISO 8583 messages and ISO 20022 messages carry different data fields. A gateway that does not map these fields correctly will lose remittance data.
Payment Gateway Licensing: Who Actually Needs a License?
A common compliance question is whether a payment gateway needs a financial license. The answer depends entirely on what the gateway touches: data or money.
The Data vs. Money Rule
If a gateway only routes encrypted payment data between the merchant and the acquiring bank, it acts as a Technical Service Provider (TSP). TSPs do not hold customer funds. In most jurisdictions, pure TSPs do not need financial transmission licenses. They must comply with security standards (like PCI DSS), but they fall outside banking regulations.
If the gateway holds funds, settles transactions directly into merchant accounts, or offers digital wallets, it touches the money flow. This triggers strict licensing requirements.
Regional Licensing Frameworks
Practitioners must map the gateway’s operational model to local licensing rules.
United States (Money Transmitter Licenses)
If a company transmits money or holds customer funds, it must register federally as a Money Services Business (MSB) with FinCEN. It must also obtain a Money Transmitter License (MTL) in almost every state where it operates. Securing 50 state MTLs takes years and significant capital. This is why most pure gateways partner with licensed acquiring banks instead of moving the money themselves.
Related: Getting a Montana MSB License: Using the U.S.’s Only “No-License” State as Your Crypto Gateway
European Union (PSD2 Authorization)
Under the Payment Services Directive (PSD2), entities that provide payment services or issue electronic money need authorization from a national regulator. They must hold a Payment Institution (PI) or Electronic Money Institution (EMI) license. A pure IT gateway is exempt under the “technical service provider” exclusion. This exemption applies only if the gateway does not negotiate or execute payment orders on behalf of the user.
India (Payment Aggregator License)
The Reserve Bank of India (RBI) strictly regulates online payment intermediaries. Entities that collect money from customers and settle it to merchants must obtain a Payment Aggregator (PA) license. The RBI mandates strict escrow account management and minimum net-worth requirements for these licensees.
The PayFac and Sponsor Bank Model
Many modern gateways operate as Payment Facilitators (PayFacs). A PayFac acts as a master merchant, onboarding smaller sub-merchants under its own umbrella. Because the PayFac controls the settlement and takes on the underwriting risk, the acquiring bank holds the PayFac strictly liable.
While the PayFac itself might not need an MTL if it uses a sponsor bank’s license, the card networks (Visa and Mastercard) require strict registration and compliance monitoring for the PayFac model. If a gateway offers “instant onboarding” for merchants, it is likely operating as a PayFac or using a similar third-party sender model.
What Practitioners Must Verify in the Contract
When reviewing a gateway contract, look past the marketing materials and check the regulatory status clause. Verify these three points:
The Vendor’s Status: Confirm if the vendor acts as a licensed Payment Institution, a registered MSB, or an unregulated TSP. Get this representation in writing.
The License Holder: If the vendor claims to be a TSP, verify who holds the actual money transmission license. Usually, it is the partner acquiring bank. The contract must name this bank.
The Fund Flow: If a vendor claims to be an unregulated TSP but routes funds through its own corporate bank account before paying the merchant, it is operating as an unlicensed money transmitter. This creates massive regulatory and financial risk for the merchant. Funds must move directly from the acquiring bank’s escrow or settlement account to the merchant.
Common Misconceptions
“The gateway stores the money.”
No. The gateway transmits data. The acquiring bank holds the merchant’s funds in a merchant account. The card network facilitates the transfer between banks.
“PCI compliance is the gateway’s problem.”
Partially. The gateway reduces the merchant’s PCI scope through tokenization and hosted payment pages. But the merchant still owns the integration layer, the website scripts, and the access controls to its own systems. PCI DSS 4.0 Requirement 6.4 makes this explicit for e-commerce payment pages.
“One gateway handles all payment methods.”
Not always. Some gateways specialize in cards. Others focus on local payment methods (UPI, Pix, iDEAL, Sofort). A merchant that sells globally may need a gateway aggregator or multiple direct integrations.
“Instant payment means instant settlement.”
No. Real-time payment rails (FedNow, UPI, SCT Inst) move the payment instruction in seconds. But the merchant’s acquiring bank may still batch the settlement. The money arrives in the merchant’s account on the settlement cycle defined in the acquirer contract.
Summary
A payment gateway is the secure transmission layer between a customer’s payment credential and the financial network that processes it. It encrypts, routes, and relays. It does not hold money.
The full payment processing system includes the gateway, the acquiring bank, the card network, the issuing bank, and the processor. Each has distinct roles and distinct regulatory obligations.
For online payments, the gateway must handle card-not-present risk, enforce Strong Customer Authentication where required, and support tokenization to limit PCI scope.
The regulatory environment changed significantly between 2022 and 2025. PCI DSS 4.0 raised the bar for script monitoring and MFA. The EU is replacing PSD2 with a tighter Payment Services Regulation. Instant-payment mandates in the eurozone and the United States changed what “real-time” means for bank rails. The SWIFT ISO 20022 migration deadline of November 2025 affects any gateway that touches cross-border transfers.
A practitioner who understands this chain can scope integrations correctly, negotiate contracts with the right questions, and identify compliance gaps before a regulator or a card audit finds them.
We write about payments regulation, fintech compliance, and the operational rules that practitioners need to get right. If you work on payment integrations, gateway contracts, or PCI scoping, this is the kind of material we produce weekly.
