Gateway Fees Explained

Gateway Fees Explained: What Merchants Pay for the Technical Payment Layer A merchant's monthly payment costs show four different categories: Gateway. Acquiring. Interchange and scheme costs. PSP charges on another part of the stack. The gateway line raises an obvious question. What exactly is the merchant paying the gateway to do that the other payment providers are not already doing? That question matters because a payment gateway is not inherently another name for payment processing. In a conventional online-card architecture, the gateway sits close to the merchant's technical environment. The UK Payment Systems Regulator describes it as technology that captures, stores and transmits card information to the acquirer, acting as an interface between the merchant's website and the acquiring side. The PSR separately describes core network processing as the transmission of payment instructions between acquirer and issuer. (PSR) That distinction gives merchants a useful way to think about gateway fees: A gateway fee is primarily a payment-infrastructure cost. It should not be mistaken for the full economic cost of accepting a payment. The merchant may still incur acquiring margin, interchange, card-network fees, payment-method fees, foreign-exchange costs, disputes and other charges outside that gateway layer.

And sometimes the merchant will not see a gateway fee at all—not because the technical functionality disappears, but because it is bundled into another commercial relationship. The RBA explicitly recognizes that online gateway services can sit within the broader category of services supplied by PSPs, while acquirers themselves can provide online card acceptance through a payment gateway. (Reserve Bank of Australia) That is why the right question is not simply: “How much is our gateway?” It is: “Which technical functions does this gateway provide, what does each cost us, and which costs and responsibilities remain elsewhere in the payment stack?”

What a payment gateway actually does At its narrowest, the gateway connects the merchant-facing payment environment with downstream payment infrastructure. A simplified card flow can look like this: Customer / checkout ↓ Payment gateway / merchant API layer ↓ Acquirer / acquiring processor ↓ Card network ↓ Issuer The response then travels back through the relevant chain. The gateway can therefore perform technical functions such as accepting payment data from the merchant environment and transmitting the relevant information toward an acquirer. The PSR specifically identifies capturing, storing and transmitting card information as gateway functions. (PSR) But real products can extend substantially beyond that narrow definition. Depending on the provider and integration, a gateway may also provide: * hosted checkout or payment fields * payment APIs * tokenization * card-data vaulting * transaction routing * connections to multiple acquiring or payment relationships * transaction status handling * retries or technical failover * reporting * fraud-tool integrations * payment-method connectivity * reconciliation data None of those capabilities should be assumed from the word gateway alone. They must be verified in the technical documentation and contract. That is the first lesson of gateway pricing: Price the functions, not the label.

Gateway versus PSP versus acquirer versus processor The terminology gets difficult because a single company may play multiple roles. The RBA defines an acquirer as a provider of card acceptance services to merchants through its participation in relevant card networks. It separately uses PSP as a broad category that can encompass acquirers, payment facilitators and gateway providers. (Reserve Bank of Australia) The cleanest merchant model is therefore functional rather than corporate. Layer Primary question Typical economic role Gateway How does the merchant's checkout/payment software connect to payment infrastructure? Technical connectivity/infrastructure Acquirer Who provides the merchant access to card acceptance and the acquiring relationship? Acceptance, processing, settlement and merchant economics Network processor How are payment instructions transmitted between acquiring and issuing sides? Network-processing infrastructure Card network Which network rules/infrastructure facilitate the card transaction? Scheme/network economics Issuer Who issued the customer's card/account? Issuer economics, including interchange where applicable PSP Which combination of these and other services is being packaged for the merchant? Potentially several layers The crucial implication is: Gateway fee ≠ interchange. Gateway fee ≠ scheme fee. Gateway fee ≠ automatically the acquirer's processing margin. And even: Gateway provider ≠ necessarily a different company from the PSP or acquirer.

That last distinction explains why two merchants can use similar technical functionality while only one receives an explicit gateway invoice.

Technical routing is not the same as financial processing The word processing causes particular confusion. A merchant may call almost everything that happens after the Pay button “processing.” Technically, several different processes can be involved. The PSR distinguishes the merchant-to-acquirer gateway layer from core processing between acquirer and issuer. Its regulatory analysis describes core processing as activities associated with authorization, clearing and settlement communications within that central part of the card-processing value chain. (PSR) So a contract labeled gateway processing fee needs to be read according to its contractual definition, not ordinary language. Ask: What is being processed? And then: When does the provider consider that processing billable? Those questions become critical once per-transaction charges enter the proposal.

How gateway pricing can work There is no requirement that gateways expose their economics in one universal format. The editorial framework for this article therefore treats the following as possible, rather than universal, gateway pricing structures: per authorization, per transaction, monthly/platform-based, separately priced technical services, or a gateway capability bundled into another provider's rate. Per-authorization pricing A merchant may be charged when an authorization is submitted. That makes the number of payment attempts important. A checkout with repeated retries could generate materially more billable gateway events than completed purchases, depending on the contract. Per-transaction pricing A gateway can instead—or additionally—define a billable transaction. But “transaction” is not precise enough for procurement. Does it mean: * every payment request? * only successful authorizations? * captures? * sales? * recurring charges? * refunds? * voids? The contract needs to define the event. Monthly or platform fee A gateway may have a recurring charge independent of payment volume. If so, annualize it. A $X monthly platform cost is not economically equivalent for a merchant processing 10,000 payments per month and another processing 10 million. Minimum commitments A gateway contract can potentially contain minimum platform spend or volume commitments.

These should be modeled at current, downside and expected-growth volumes rather than evaluated only at the provider's most attractive volume level. Feature or service fees Some capabilities may be included in the base gateway relationship while others may be separately priced. Possible examples include tokenization, vault services, new processor/acquirer connectors, routing functionality, risk integrations, premium reporting, support or implementation services. Again, there is no universal bundle. Bundled gateway economics A PSP or acquirer can also provide the technical gateway without exposing a distinct gateway charge. The RBA's payment-services taxonomy explicitly accommodates this overlap. (Reserve Bank of Australia) The absence of a gateway line item therefore does not establish that gateway functionality has zero economic cost. It means the merchant may not be able to isolate that cost from the provider's bundled commercial model.

The most important gateway-pricing question: what is the denominator? Gateway pricing frequently becomes misleading because teams compare prices without first comparing billing events. Suppose a merchant records: * 1,000,000 gateway payment attempts * 920,000 authorization approvals * 900,000 completed paid orders A provider charging per gateway request creates different economics from a provider charging only for completed successful payments. So merchants should maintain three distinct concepts: Payment attempt A request that entered the relevant payment flow. Successful payment A payment successfully authorized/captured according to the merchant's defined methodology. Completed paid order A commercial order the merchant ultimately recognizes as successfully paid. The denominator matters because failed payments can still consume gateway resources and may still be billable. A checkout with poor payment performance can therefore produce a low-looking gateway price per event but a much higher gateway cost per successful payment.

A hypothetical gateway-cost example

Assume a gateway proposal contains: * $4,000 monthly platform fee * $0.03 per billable authorization attempt And the merchant generates: * 1,000,000 billable attempts * 900,000 successful paid orders Monthly gateway cost would be: $4,000 + ($0.03 × 1,000,000) = $34,000 Gateway cost per attempt: $34,000 ÷ 1,000,000 = $0.034 Gateway cost per completed paid order: $34,000 ÷ 900,000 ≈ $0.0378 The quoted variable fee was three cents. The economically allocated gateway cost per completed order is closer to 3.8 cents after the fixed fee and failed attempts are included. Nothing is wrong with either number. They answer different questions. That is why gateway procurement should never compare one provider's per successful transaction fee with another provider's per authorization fee without normalizing the denominators.

Bundled versus standalone gateway This is the central architecture decision. Bundled gateway A merchant uses a PSP or acquirer that incorporates the technical payment layer into its broader service. Potential advantages can include: * fewer contracted vendors * fewer integrations * simpler operational ownership * potentially simpler reconciliation * one support path * less need to maintain independent provider connections The potential disadvantage is that the technical layer may be harder to separate from the financial relationship. If the merchant later wants to change acquirers, add processors or move parts of its payment stack, the degree of portability depends on the specific technology, data model, tokens, contracts and APIs. Standalone gateway A merchant separately contracts the technical gateway while maintaining one or more underlying payment or merchant-account relationships. That creates another explicit cost and another vendor dependency. But it can also create a useful architectural boundary.

That is a concrete example of the architecture this article is discussing: merchant technical integration → independent gateway layer → existing downstream payment relationships. It does not prove that the standalone approach is better or cheaper for every merchant. It shows why a gateway can exist as a distinct layer at all.

What are merchants buying with a standalone gateway? The real business case usually sits in one or more of five areas. 1. Connectivity A gateway can potentially reduce the number of direct connections the merchant must build and maintain. The economic question is not merely how many processors the gateway advertises. It is: How many connections would this merchant otherwise have to engineer, certify, operate and maintain? 2. Abstraction A merchant may value a common API or transaction model across downstream providers. That can reduce the amount of provider-specific payment logic embedded directly in checkout systems. But “single API” does not mean all downstream behavior becomes identical. Authorization semantics, settlement, disputes, data fields and payment-method behavior can still vary. 3. Routing and control Some gateway products can provide transaction-routing capability.

But routing is not a universal gateway function. Procurement should establish: * what can be routed, * between which endpoints, * according to which rules, * who configures them, * whether failover exists, * what data is available to the routing logic, * and whether routing carries additional fees. The broader architectural design belongs in International Payment Architecture. This article owns only the cost/value question attached to the gateway layer. 4. Tokenization and vaulting A gateway may tokenize payment credentials or maintain a payment-data vault. PCI SSC describes tokenization as replacing a primary account number with a surrogate token. Its guidance explains that this can reduce the presence of PAN data in parts of a merchant environment, although the security and PCI implications depend on the implementation. (PCI Security Standards Council)

Tokenization deserves particularly careful procurement review because token existence does not automatically equal token portability. Before paying a premium for vaulting, ask: * Who owns or controls the tokens? * Are they provider-specific? * Can they be exported? * Can they be used with another acquirer? * What happens on termination? * Can recurring credentials migrate? * Who performs detokenization? * Which environment remains in PCI scope? Do not assume the answers. 5. Reporting and operations The gateway can also become an operational data layer.

That capability has value only if the merchant's finance, support or payments teams actually eliminate work or gain information they could not obtain efficiently elsewhere. A second dashboard that duplicates the acquirer's data does not automatically justify another infrastructure fee.

Gateway infrastructure and PCI DSS Security architecture can create economic value, but it needs precise wording. Outsourcing card-data handling does not make PCI DSS obligations disappear. PCI SSC states that merchants outsourcing payment processing still retain responsibilities concerning provider compliance, agreements, monitoring and their own PCI validation obligations, even though many technical requirements may no longer apply directly to their own environment. (PCI Security Standards Council) PCI SSC's current guidance also distinguishes among redirect, embedded and other e-commerce implementations when determining particular SAQ requirements. (PCI Security Standards Council) Therefore, do not justify a gateway fee by saying: “The gateway removes PCI compliance.” A more defensible merchant question is: “Does this integration materially change our card-data exposure, validation scope, security responsibilities or cost of maintaining the payment environment?” That impact should be reviewed with the merchant's PCI adviser, acquirer or other compliance-accepting entity.

The Gateway Cost Checklist Before approving a gateway proposal, answer these ten questions. Question What the merchant needs to establish 1. Is it per transaction? What exactly qualifies as a transaction? 2. Is it per authorization? Are failed attempts, retries, reversals or duplicate submissions billable? 3. Is there a monthly/platform charge? What is the annual fixed cost and are there minimum commitments? 4. Does pricing include vaulting? Which credentials are stored and under whose control? 5. Does it include tokenization? What token type, portability and lifecycle apply? 6. Does it include routing? Which providers/acquirers can be routed and what rules or charges apply? 7. Does it include reporting? Which reports, APIs, retention periods and export rights exist? 8. Does it support multiple acquirers? Which connections are live for the merchant's actual markets and use cases? 9. Does it connect local payment methods? Which methods, countries and technical interfaces are genuinely available? 10. What remains outside the gateway price? Acquiring, interchange, schemes, payment methods, FX, fraud, disputes, settlement and any other relevant costs The tenth question is the most important. A gateway quote may be perfectly transparent and still represent only a small slice of total payment economics.

Measure gateway cost three ways A useful scorecard separates variable gateway economics from fixed infrastructure cost and downstream payment performance. 1. Gateway cost per attempt Gateway cost per attempt = Gateway costs attributable to the measured period ÷ Billable or measured payment attempts State whether fixed platform fees are included. If they are, label the metric fully loaded gateway cost per attempt. 2. Gateway cost per successful payment Gateway cost per successful payment = Gateway transaction charges * attributable gateway platform fees * gateway-specific add-ons ÷ successful payments This metric captures the effect of failed attempts. 3. Monthly fixed gateway cost Track separately: * base platform charge * minimum spend * connection charges * vault/platform fees * support costs * other recurring gateway costs Do not bury a large minimum commitment inside an average per-transaction rate.

Then measure the technical value Pure gateway pricing still does not tell the merchant whether the gateway is worth having. Track alongside cost: Architecture metric Why it matters Acquirer/provider connections enabled Shows actual integration consolidation Payment-method connections enabled Shows technical access created Merchant integrations avoided Proxy for duplicated engineering effort avoided Engineering hours maintaining payment connectors Measures ongoing technical burden Payment incidents by connection Helps evaluate resilience Routing usage Shows whether paid routing capability is actually used Reporting/reconciliation effort Tests operational value Migration effort Reveals whether architecture truly improves portability Engineering savings are not payment-processing fees. They are internal operating economics. Keep them separate, then combine them only when evaluating the business case for the architecture.

When does a separate gateway actually pay off? A standalone gateway is most defensible when the merchant can identify a capability that would otherwise require meaningful internal work or create unwanted dependency. Possible cases include: Multiple acquiring relationships The merchant needs several acquirers but prefers not to maintain completely independent checkout integrations for each one. Merchant wants technical independence from acquiring The merchant wants the ability to modify underlying financial providers without rebuilding as much customer-facing payment infrastructure. That benefit is only real if the gateway's contracts, APIs and stored credentials are sufficiently portable. The gateway provides meaningful routing The merchant actually uses the layer to choose among available downstream routes according to approved commercial or performance logic. Centralized payment-data functionality matters The merchant derives real value from tokenization, vaulting or a common payment-data model. Integration maintenance is expensive The gateway avoids enough direct integrations, certifications, upgrades and incident-response work to offset its own cost. The gateway creates useful visibility Reporting materially improves transaction investigation, reconciliation or payment operations rather than merely reproducing existing acquirer reports. In each case, the gateway earns its fee by solving an architecture problem.

When the additional gateway probably does not earn its fee The separate layer becomes harder to justify when: * one PSP already provides all required connectivity, * the merchant has no realistic need for multiple acquiring relationships, * the standalone gateway does not create useful portability, * tokenization remains locked to the gateway, * routing is licensed but rarely used, * reporting duplicates downstream providers, * an additional integration increases incidents or reconciliation work, * minimum fees dominate low transaction volumes, * the merchant is paying separate providers for overlapping functionality. That does not necessarily mean the gateway should be removed. It means the merchant needs a better explanation of what it is purchasing.

Bundled versus standalone: compare architecture, not invoice labels Consider two proposals.

Architecture A Architecture B Gateway Standalone Bundled Acquirer Separate Included or integrated Gateway fee visible? Yes Possibly not Multi-acquirer capability Verify Verify Token portability Verify Verify Routing Verify Verify Reporting Verify Verify Engineering requirements Model Model Total payment cost Model Model It would be a mistake to conclude that Architecture B has the cheaper gateway simply because its gateway charge is $0. The cost is not necessarily zero. It is unallocated. At the same time, it would be equally misleading to invent an estimated “embedded gateway margin” without evidence. If a bundled provider does not expose its gateway economics, compare: total payment cost + architecture capability + engineering/operating cost against the standalone alternative. Do not manufacture a component rate that the contract does not disclose.

What gateway fees can merchants negotiate? Unlike statutory charges or many network-defined costs, a gateway's commercial price is a contractual provider charge. That makes it appropriate to test commercial flexibility—but not to assume every term is negotiable. Key discussion points include: * per-authorization charge * per-transaction charge * definition of a billable event * retry treatment * volume tiers * monthly/platform fee * minimum commitments * implementation charges * processor/acquirer connector fees * tokenization or vaulting charges * routing charges * premium support * reporting/API access * contract length * termination terms * data export * token migration * SLA and service credits * development/test environment terms One of the strongest questions is: “Which parts of this price grow with our usage, and which parts grow because our architecture becomes more complex?” Those are different cost drivers and should be negotiated differently.

What should remain outside the gateway analysis? Do not make the gateway article carry the entire cost stack. Interchange Interchange is an issuer-side card economic layer, not a gateway charge. The RBA describes interchange as paid by the merchant's acquirer to the card issuer. (Reserve Bank of Australia) Link to Interchange Fees Explained. Scheme/network fees Card networks charge scheme fees for their own services. These are economically distinct from gateway pricing. (Reserve Bank of Australia) Link to Card Scheme Fees Explained. Acquirer margin An acquirer provides the card-acceptance relationship and has its own commercial economics. Link to Acquiring Fees Explained. PSP markup If a PSP bundles gateway functionality together with multiple other capabilities, how its commercial margin should be decomposed belongs in PSP Markup Explained. Full multi-provider architecture Whether the merchant should adopt orchestration, abstraction or multi-PSP routing as a broader operating strategy belongs in International Payment Architecture. This article should answer only: What is the technical payment layer costing, and what is the merchant getting in return?

Those are relevant capabilities for this article because they illustrate what merchants may be buying from the technical layer. They do not, by themselves, establish:

* universal multi-acquirer compatibility, * universal token portability, * a specific engineering saving, * an authorization uplift, * or a lower total processing cost. Those conclusions require the merchant's architecture and an approved commercial proposal.

The gateway decision to optimize The cheapest standalone gateway is not automatically the best gateway. Neither is a bundled gateway automatically economical because it has no visible gateway charge. The decision should start with a cost map: What enters the gateway? What leaves it? Which providers can it connect? Which data does it own or store? Which technical work does it eliminate? Which fees are triggered when it is used? And which payment costs still exist downstream? Then calculate the gateway's fully loaded cost per attempt and per successful payment. Finally, compare that amount with the architectural value the merchant actually receives. If the gateway improves connectivity, control, portability, maintainability or operational visibility enough to justify another layer, the separate fee can be rational infrastructure spending. If it merely reproduces capabilities already supplied elsewhere, the problem is not that gateways are inherently expensive. The problem is that the merchant may be paying twice for the same architecture.

Technical and pricing FAQ Is a gateway fee the same as a payment-processing fee? No universal equivalence should be assumed. The PSR distinguishes a gateway at the merchant-to-acquirer interface from core network processing between acquirer and issuer. Provider terminology can vary, so the contract's definition of “processing” must still be checked. (PSR) Does every online merchant pay a separate gateway fee? No. Gateway functionality may be supplied by an acquirer or another PSP rather than contracted as a standalone product. The RBA's current taxonomy explicitly recognizes gateway providers as one type of PSP and notes that acquirers can provide online acceptance through gateways. (Reserve Bank of Australia) Can a failed payment still create a gateway charge? It can if the contract bills an authorization, API request, payment attempt or another event that occurs before the payment succeeds. Merchants should therefore verify the precise billable event rather than assume fees apply only to completed purchases. Does tokenization eliminate PCI DSS obligations? No. PCI SSC states that outsourcing payment processing does not eliminate the merchant's responsibilities under PCI DSS, even though many requirements may no longer apply directly to the merchant's own environment. (PCI Security Standards Council) Is a standalone gateway better for a multi-acquirer strategy?

Potentially, but not automatically. The merchant must verify actual downstream connectivity, routing, credential portability, commercial terms and operational complexity. A gateway that technically sits between merchant and several providers can create abstraction; whether that creates sufficient economic value is merchant-specific. Should gateway fees be measured as a percentage of transaction value? They can be, but a percentage alone can obscure the economics if pricing is primarily fixed or per attempt. Cost per attempt and cost per successful payment usually expose the technical-layer economics more directly.

This article provides general information and does not constitute legal, regulatory, financial, tax, accounting, security, PCI-compliance or commercial advice. Merchants should verify current pricing, contractual terms, technical specifications, network rules, compliance responsibilities and regulatory requirements with qualified advisers, payment providers, acquirers, card networks and relevant authorities. Practical asset: Gateway Cost Checklist For a downloadable version, I would turn the framework into a three-stage audit. Stage 1 — Identify the billing unit Item Contract answer Merchant data Per authorization?

Monthly authorization count Per attempt/API call?

Monthly attempt count Per successful transaction?

Successful payment count Monthly/platform?

Annualized fixed cost Minimum commitment?

Downside-volume exposure Stage 2 — Identify the functionality Capability Included? Separately priced? Actually used? Payment API

Tokenization

Multi-acquirer connectivity

Local-method connectivity

Fraud integrations

Reporting

Reconciliation

Premium support

Stage 3 — Identify everything outside the quote Cost outside gateway Provider/owner Included elsewhere? Interchange Issuer economics

Scheme/network Card network

Acquiring Acquirer

PSP markup PSP

Method fee Relevant method/provider

FX Relevant converter/provider

Disputes Contract-specific

Fraud service Relevant provider

Merchant account charges Contract-specific

The worksheet should finish with: If we removed this gateway tomorrow, which capability would we have to rebuild, replace or give up? That question turns gateway pricing from invoice inspection into architecture economics.

Measurement plan Metric Formula/treatment Gateway cost per attempt Gateway costs ÷ gateway attempts Variable gateway cost per attempt Attempt-based gateway fees ÷ billed attempts Gateway cost per successful payment Gateway-specific costs ÷ successful payments Monthly fixed gateway cost Platform + minimum + fixed add-ons Annual fixed gateway cost Monthly fixed amounts × applicable months + annual charges Connections enabled Live usable acquirer/provider connections Connection utilization Volume actually flowing through each connection Engineering maintenance Internal hours/cost attributable to gateway/payment connectors Incidents Gateway-related payment incidents and duration Routing utilization Transactions actually subject to gateway routing Reconciliation workload Internal payment/finance effort attributable to gateway data Migration portability Documented ability and estimated effort to move connections/data/tokens

Negotiation checklist Before signing or renewing a standalone gateway, ask the provider to document: 1. Exact definition of every billable event. 2. Whether failed authorizations and retries are charged. 3. Treatment of voids, refunds and reversals. 4. Fixed platform and monthly minimums. 5. Volume-tier calculation. 6. Connector setup and recurring connector fees. 7. Tokenization and vault pricing. 8. Token ownership, export and portability. 9. Routing pricing and configuration rights. 10. Reporting/API charges or usage limits. 11. Sandbox/development environment terms. 12. Implementation charges. 13. SLA and support tiers. 14. Data retention and export rights. 15. Termination and migration support. 16. PCI/shared-security responsibilities. 17. Which features are optional versus contractually required. 18. Which fees can change during the term.

I treated Editorial Brief 8 as the controlling document. This article therefore owns the technical payment layer and its cost: what the gateway is being paid to do, how that cost can be exposed or bundled, and when paying for a separate gateway creates enough architectural value to justify another line item. It deliberately does not turn into another article about acquiring, interchange, scheme fees, PSP markup, or multi-PSP architecture. Editorial interpretation Field Direction Merchant payment-cost problem The merchant sees a gateway charge but cannot tell whether it is paying for unique infrastructure or duplicating capabilities already supplied by its PSP, acquirer, processor, vault, or orchestration layer. Fee layer owned Technical payment-connectivity/infrastructure cost. Fee owner A standalone gateway provider when separately contracted; otherwise gateway functionality may be embedded in a PSP/acquirer commercial relationship. Unique evidence anchor Gateway functionality can exist as a distinct technical interface between merchant and acquirer, but the same functionality can also be supplied inside a broader PSP/acquiring service. Editorial position A separate gateway fee is justified when the layer creates enough control, portability, connectivity, operational efficiency, or useful technical capability to outweigh its incremental cost. Assumption challenged “Gateway fee” and “payment processing fee” are simply different labels for the same charge. Primary cost variables

Billing event, transaction/authorization volume, fixed platform fees, volume tiers, tokenization/vaulting, routing, connections, reporting and other separately priced services. Merchant decision Does paying for a distinct gateway improve the economics or resilience of the merchant's payment architecture relative to receiving gateway functionality inside another provider relationship? Selected format Payment architecture cost map. Structural rationale Follow the transaction from merchant software to the financial acceptance layer, identify what the gateway actually performs, and then attach cost to those functions. Original asset Gateway Cost Checklist. Primary metrics Gateway cost per attempt; gateway cost per successful payment; monthly fixed gateway cost; connections enabled; measured engineering/maintenance effect. The architecture distinction in the brief is well supported. The UK Payment Systems Regulator describes a payment gateway as the technology that captures, stores and transmits card information to the acquirer and acts as the interface between the merchant website and acquirer. Importantly, it places the gateway outside the core network-processing function between acquirer and issuer. (PSR)

The organizational labels are less clean than the architecture. The Reserve Bank of Australia treats “PSP” as a broad term that can include acquirers, payment facilitators and providers of online payment gateway services. So “gateway versus PSP” is primarily a functional distinction; one company may provide both. (Reserve Bank of Australia)

Proposed architecture 1. The fee before the financial payment layer 2. What a payment gateway actually does 3. Gateway versus PSP, acquirer and processor 4. How gateway pricing can work 5. Why the billing denominator matters 6. Bundled versus standalone gateways 7. Tokenization, vaulting, routing and reporting 8. The Gateway Cost Checklist 9. Measuring gateway economics 10. When the separate layer pays for itself 11. What merchants can negotiate 12. Final recommendation 13. Technical/pricing FAQ

Complete article SEO and publishing package SEO title: Gateway Fees Explained: Payment Gateway Costs & Pricing H1: Gateway Fees Explained: What Merchants Pay for the Technical Payment Layer Meta description: Learn how payment gateway fees work, what gateways actually provide, how standalone and bundled gateway pricing differ, and how merchants should measure gateway cost per payment. URL slug: /payments-pricing-fundamentals/gateway-fees-explained Primary keyword: gateway fees explained Secondary keywords: payment gateway fees; gateway transaction fees; payment gateway pricing; merchant gateway cost; gateway monthly fees; payment API fees; payment gateway vs PSP fees; ecommerce gateway pricing Related entities: payment gateway, payment API, PSP, merchant acquirer, processor, authorization, payment tokenization, payment vault, payment routing, cardholder data, PCI DSS, payment orchestration, hosted checkout, server-to-server payment integration Article excerpt: A payment gateway is the technical interface connecting a merchant's checkout to downstream payment infrastructure. Sometimes merchants buy that layer separately; sometimes a PSP or acquirer bundles it. The important question is not whether a gateway fee exists, but what infrastructure the merchant receives for the cost. Suggested structured data: Article and BreadcrumbList. Use FAQPage only if the FAQ is published visibly and current search-engine eligibility is verified before launch.

Internal links Recommended anchor Destination PSP markup PSP Markup Explained acquiring fees Acquiring Fees Explained how payment processing fees work How Payment Processing Fees Work read a PSP pricing proposal How to Read a PSP Pricing Proposal multi-provider payment architecture International Payment Architecture interchange fees Interchange Fees Explained card scheme fees Card Scheme Fees Explained The important boundary is that International Payment Architecture should own whether and how the merchant builds a multi-provider abstraction/routing strategy; this article owns the economic justification for paying the gateway layer that might enable part of that architecture. Authoritative source recommendations 1. UK Payment Systems Regulator — Market Review of Scheme and Processing Fees, Annex on Processing Services. This is the strongest neutral source for distinguishing the gateway at the merchant/acquirer edge from core processing between acquirer and issuer. (PSR) 2. Reserve Bank of Australia — Merchant Card Payment Costs and Surcharging Glossary. Strong current source for the functional relationship among gateway providers, PSPs, payment facilitators and acquirers and for keeping gateway cost distinct from interchange and scheme economics. (Reserve Bank of Australia)

3. PCI Security Standards Council — FAQ on Outsourced Payment Processing. Current 2025 clarification that outsourcing can reduce the requirements directly applicable to a merchant environment without eliminating merchant PCI responsibility. (PCI Security Standards Council) 4. PCI Security Standards Council — Tokenization Guidance. Useful for the technical definition of tokenization and the relationship among tokens, PANs and card-data vaults. Because the core tokenization information supplement is older, its concepts should be checked against the current PCI DSS version and current PCI FAQs at publication. (PCI Security Standards Council)

Supporting visual Gateway Cost Checklist: What Are You Actually Paying For? Visual layout: MERCHANT CHECKOUT ↓ GATEWAY — TECHNICAL LAYER Inside the gateway box: API connectivity Tokenization / Vault Routing Acquirer connections Payment-method connections Reporting ↓ ACQUIRER ↓ CARD NETWORK ↓ ISSUER Beside the gateway box: Possible gateway pricing * Per authorization * Per transaction * Monthly/platform * Connection fees * Add-on services * Or bundled elsewhere Then a large bottom box: BEFORE COMPARING PRICES, ASK: What is the billable event? What does the gateway include? What remains outside it? What would we have to rebuild without it? Footer callouts: Gateway fee ≠ interchange Gateway fee ≠ total payment cost No separate gateway fee ≠ no gateway economics Image alt text: “Payment gateway cost map showing the technical gateway layer between merchant checkout and acquirer, including API connectivity, tokenization, routing, payment connections and reporting, with a gateway pricing checklist.”

Human contribution Do not invent named contributors. Recommended publication ownership: Author: Payments infrastructure or payment-architecture specialist. Technical reviewer: Payments engineering lead or architect with direct API/gateway integration experience. Commercial reviewer: Merchant finance or payment-pricing specialist. Security reviewer: PCI/payment-security specialist if the tokenization, vault or PCI section remains substantial. Include a last reviewed date only after the reviews occur.

Publication fact-check matrix Pricing fact checks Before publication or before adding provider examples, verify: * Exact gateway pricing unit. * Whether authorization attempts are billable. * Whether declines are billable. * Retry treatment. * Capture and sale treatment. * Refund/void/reversal fees. * Platform fee. * Monthly minimum. * Transaction minimum. * Volume tiers. * Connector charges. * Tokenization fees. * Vault fees. * Routing fees. * Reporting/API charges. * Support charges. * Implementation/setup fees. * Current effective date. * Currency and tax treatment. * Whether fees are standalone or bundled. No specific public gateway rate should be represented as a market norm. Fee-owner fact checks Confirm for every proposal: Fee Correct owner to establish Gateway/API charge Gateway provider or bundled service provider Interchange Issuer-side card economics Scheme fee Card network Acquirer margin Acquirer PSP margin PSP where separately applicable Vault fee Actual vault/service provider Fraud fee Actual risk-service provider Connector fee Contracting technical provider FX Entity performing/contributing the conversion economics Do not infer ownership from invoice labels.

Network/interchange fact-check items This article should contain no interchange-rate tables and no card-network fee schedules. If either is added later: * verify network, * geography, * merchant location, * issuer/card geography, * card type, * transaction type, * effective date, * regulatory treatment, * and whether the amount is truly pass-through. The gateway should never be described as the recipient of interchange merely because it transmits the transaction. The RBA distinguishes interchange, scheme fees and PSP/acquirer costs. (Reserve Bank of Australia)

Provider/acquirer fact-check items Before describing any gateway/acquirer relationship, verify: * Who contracts with the merchant. * Who actually provides the gateway. * Who is the acquirer. * Who operates the processor connection. * Which entity stores credentials. * Who creates tokens. * Where detokenization occurs. * Which connections are currently supported. * Which connections are actually enabled for the merchant. * Whether “multiple acquirers” means technically available or contractually usable. * Who controls routing. * Who owns the transaction data. * How settlement reporting is produced. * Whether settlement itself is provided by the gateway or merely reported by it.

Merchant-model assumptions The article's numerical gateway-cost example is explicitly hypothetical. A merchant-specific model needs: * monthly payment attempts * authorizations * declines * retries * captures * successful payments * completed paid orders * transaction values * currencies * payment methods * gateway billing units * current fixed costs * current connector count * current engineering workload * planned acquiring/provider expansion * reporting/reconciliation workload * incident data * token/vault requirements Do not use a generic average transaction as the basis for procurement if actual attempt and success data are available.

Proposal and statement fact-check items For a real gateway proposal, reconcile: Proposal → contract → gateway usage data → monthly invoice → PSP/acquirer invoice → settlement reporting → accounting Look specifically for duplicate or ambiguous labels such as: * processing * transaction * authorization * API * platform * gateway * connectivity * routing * vault * token * payment method * risk If a bundled provider does not disclose a gateway component, mark it: Gateway cost: not separately observable Do not invent an allocation.

Regulatory and security fact-check items * Verify current PCI DSS version and applicable SAQ/assessment requirements immediately before publication. * Do not present tokenization as eliminating PCI obligations. * Do not assume a redirect, iframe and direct card-data integration have identical PCI implications; PCI SSC's current guidance distinguishes them. (PCI Security Standards Council) * Determine the relevant jurisdiction before making any statement about whether a particular gateway/provider activity constitutes a regulated payment service. * Distinguish security standards, card-network requirements and law. * Preserve the general-information disclaimer.

Amber-flag claims Claim Treatment “Gateways normally cost $X” Do not publish without defined market/source “A gateway charges every authorization” Provider-specific “Failed transactions are always charged” Contract-specific “Tokenization removes PCI requirements” False/overbroad “Standalone gateways reduce engineering cost” Requires merchant-specific measurement “Multi-acquirer routing improves approval by X%” Requires controlled merchant evidence “Independent vaulting eliminates provider lock-in” Depends on portability and contract “Bundled gateway is free” Unsupported unless explicitly contractually priced at zero and scope defined “Separate gateway is cheaper” Requires full architecture model “Separate gateway is more reliable” Requires actual architecture/availability evidence

Requires approved current commercial data

Requires auditable merchant evidence

* Current SpiderPipe product positioning. * Current merchant-account integrations. * Which downstream processors/acquirers can currently be connected. * Which connections are commercially available by merchant/market. * Current routing functionality. * Routing-control model. * Current reporting functionality. * Tokenization functionality. * Vault/storage behavior. * Token portability/export. * Current PCI DSS certification/status and approved public wording. * Current integration options. * Local-payment-method connectivity. * Implementation/support model. * Gateway pricing structure. * Connector pricing. * Platform/minimum fees. * Any routing or value-added-service pricing. * Contract termination/data migration provisions. * Any merchant performance or engineering-efficiency claim.

Cluster sameness-audit fields Audit field Gateway Fees Explained Title Gateway Fees Explained: What Merchants Pay for the Technical Payment Layer Opening device Merchant sees gateway + acquiring + card costs and asks what the gateway is actually doing Merchant problem Technical charge appears duplicative Fee owner Gateway/technical provider Primary fee type Technical infrastructure Primary format Payment architecture cost map Evidence anchor Gateway can be standalone or bundled Editorial position Separate gateway fee must purchase sufficient architectural value Merchant decision Separate gateway vs bundled technical layer Original framework Gateway Cost Checklist Primary metric Gateway cost per attempt / successful payment Hypothetical example One million attempts + fixed gateway/platform cost Core distinction Technical connectivity ≠ financial acceptance economics Conclusion Pay for the separate layer when it solves a real architecture problem FAQ style Technical/pricing scenarios Deliberately avoided opener Total card-fee waterfall Deliberately avoided thesis “Provider markup is too high” Deliberately avoided territory Acquirer risk pricing, interchange mechanics, scheme-fee taxonomy, full orchestration architecture Distinct from Acquiring Fees article Acquiring article follows institutional risk; this one follows software/infrastructure layers Distinct from PSP Markup Does not decompose PSP commercial margin Distinct from International Payment Architecture

Evaluates the gateway layer economically rather than designing the full multi-provider stack The strongest editorial line for the piece is: A gateway fee is not the price of accepting the payment. It is the price of the technical layer that gets the payment to the parties that can accept and process it. And the strongest merchant test is: If we removed the gateway, what would we have to rebuild, reconnect, maintain, or give up? If the answer is substantial and measurable, the separate gateway fee may be one of the more rational infrastructure costs in the payment stack. If the answer is “almost nothing,” the merchant has found the line item that deserves investigation.