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.

•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?

•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.

•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.

•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.

•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

•Is it per transaction?

What exactly qualifies as a transaction?

•Is it per authorization?

Are failed attempts, retries, reversals or duplicate submissions billable?

•Is there a monthly/platform charge?

What is the annual fixed cost and are there minimum commitments?

•Does pricing include vaulting?

Which credentials are stored and under whose control?

•Does it include tokenization?

What token type, portability and lifecycle apply?

•Does it include routing?

Which providers/acquirers can be routed and what rules or charges apply?

•Does it include reporting?

Which reports, APIs, retention periods and export rights exist?

•Does it support multiple acquirers?

Which connections are live for the merchant's actual markets and use cases?

•Does it connect local payment methods?

Which methods, countries and technical interfaces are genuinely available?

•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.

•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.

•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.

•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

Vault

Routing

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:

•Exact definition of every billable event.

•Whether failed authorizations and retries are charged.

•Treatment of voids, refunds and reversals.

•Fixed platform and monthly minimums.

•Volume-tier calculation.

•Connector setup and recurring connector fees.

•Tokenization and vault pricing.

•Token ownership, export and portability.

•Routing pricing and configuration rights.

•Reporting/API charges or usage limits.

•Sandbox/development environment terms.

•Implementation charges.

•SLA and support tiers.

•Data retention and export rights.

•Termination and migration support.

•PCI/shared-security responsibilities.

•Which features are optional versus contractually required.

•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

•The fee before the financial payment layer

•What a payment gateway actually does

•Gateway versus PSP, acquirer and processor

•How gateway pricing can work

•Why the billing denominator matters

•Bundled versus standalone gateways

•Tokenization, vaulting, routing and reporting

•The Gateway Cost Checklist

•Measuring gateway economics

•When the separate layer pays for itself

•What merchants can negotiate

•Final recommendation

•Technical/pricing FAQ

Complete article

SEO and publishing package

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

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

•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)

•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)

•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)

•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.