Fee payment gateway

Fee payment gateway with a transparent stack — not a blended rate.

topropay's fee model is one line per fee component: interchange and scheme fees pass through where the underlying acquirer supports it, the acquirer markup is its own line, and the platform fee is a per-authorisation charge on top. Cost-weighted routing picks the lowest landed cost per transaction.

Book a pricing review Read the API docs
One reconciliation row · five fee components.
Pass-through
interchange + scheme fees
Per-auth
platform fee, no retainer
Routing
cost-weighted policies per BIN
0 €
monthly minimum

Fee stack

Anatomy of a payment gateway transaction fee

Five fee components add up to the merchant's landed cost on a card authorisation. The platform makes them visible per row instead of bundling them into one blended rate.

  1. 01

    Interchange

    The fee the issuing bank earns on every card authorisation. Set by the card schemes (Visa, Mastercard, Amex) per BIN range, scheme tier, country pair and transaction type. Passes through on topropay where the underlying acquirer supports interchange-plus.

  2. 02

    Scheme fees

    The fees the card scheme itself earns — Visa, Mastercard's per-transaction and per-volume assessment fees. Smaller than interchange but always present on a card authorisation.

  3. 03

    Acquirer markup

    The acquirer's own margin on top of interchange + scheme. Varies by acquirer, vertical, BIN profile and chargeback band. Pass-through where supported; blended where the underlying acquirer ships blended pricing only.

  4. 04

    Platform fee

    topropay's per-authorisation fee for the orchestration layer — routing engine, vault, signed webhooks, operator portal, reconciliation feed. Surfaced as a separate line on the invoice, not bundled into interchange. No platform retainer and no monthly minimum.

  5. 05

    Optional risk fee

    Where the underlying acquirer or scheme applies an explicit processor transaction risk fee (chargeback-band-driven, MCC-driven), it surfaces as a separate line on the reconciliation row. topropay doesn't add a markup to it; the upstream figure passes through.

Key benefits

What changes with cost-weighted routing and transparent payment gateway transaction charges

Four outcomes that show up consistently once the merchant runs cost-weighted routing across many acquirers and sees the fee stack per row.

  1. 01

    Transparent payment gateway transaction fee stack

    Every authorisation surfaces with the interchange, scheme, acquirer markup and platform fee broken out — not bundled into one blended rate. The merchant's finance team sees what was paid to whom and why, per transaction.

  2. 02

    Cost-weighted routing across acquirers

    When the merchant picks cost-weighted routing, the engine picks the connected acquirer with the lowest landed cost for that specific BIN, scheme and country pair. The lowest transaction fee payment gateway behaviour isn't a sticker price — it's a routing decision per authorisation.

  3. 03

    No platform retainer, no monthly minimum

    There's no fixed cost to keep the gateway open. Pay per authorisation on top of underlying acquirer economics; the platform fee scales with volume. Sandbox is unmetered; payment gateway api testing doesn't add to the invoice.

  4. 04

    Honest about 'zero' — interchange and scheme fees always apply

    True 'payment gateway with zero transaction fee' is rare and usually means a surcharge model that shifts the fee to the buyer at checkout. topropay doesn't pretend interchange goes away; we make it visible and route around the most expensive BINs where the merchant's policy allows.

Payment gateway transaction flow

From authorisation request to reconciliation row in five stages

What happens between the merchant's POST and a reconciliation row that finance can close the month against — including which fees land on which step.

  1. 01

    Authorisation request

    Merchant POSTs to /v1/payments with amount, currency, method and (for returning shoppers) vault token. Idempotency key on the request prevents duplicate authorisations on retries.

  2. 02

    Routing engine scores the request

    BIN, scheme, currency, country pair and risk signals decide which connected acquirer runs the authorisation. Cost-weighted policies pick the lowest-landed-cost route; approval-weighted policies pick the most likely to clear.

  3. 03

    Acquirer authorisation

    The chosen acquirer sends the authorisation through the scheme to the issuer. If the issuer declines and the decline is soft, the cascade rotates to the next ranked acquirer inside the same request.

  4. 04

    Capture and settlement

    Funds capture against the acquirer; settlement flows to the merchant on the acquirer's cycle. Interchange, scheme fee, acquirer markup and topropay's platform fee all surface as separate lines on the reconciliation row.

  5. 05

    Reconciliation export

    Daily exports tag every authorisation with the acquirer ID, BIN, routing policy and full fee breakdown. Finance sees what was paid to whom for each transaction.

Main use cases

Where cost-weighted routing on a fee payment gateway earns its keep

Six merchant shapes where transparent fees and cost-weighted routing compound into measurable savings — DTC, SaaS, marketplaces, B2B, travel and PSPs.

  • DTC

    Online retail with thin card margins

    DTC merchants on commodity-product margins benefit most from cost-weighted routing — the per-transaction savings on interchange aren't huge per authorisation, but they compound at volume. The same payment gateway transaction routes per-BIN to the cheapest connected acquirer.

  • SaaS

    Subscriptions with renewal volume

    Recurring SaaS billing favours cost-weighted routing on renewals (where the customer is established and approval is rarely the bottleneck). Network tokens and updaters keep the recurring stream alive while the platform routes each charge through the cheapest available acquirer.

  • Plat

    Marketplaces with per-seller fee constraints

    Marketplaces with thin per-seller margins need per-tenant routing policies. Cost-weighted on payouts and bulk debits; approval-weighted on consumer-side authorisations. Same orchestration layer, two policies in parallel.

  • B2B

    B2B invoicing with corporate-card BINs

    Corporate-card BINs carry higher interchange than consumer BINs. Routing per BIN to the acquirer with the best corporate-card rate compresses the merchant's per-authorisation cost without changing the customer flow.

  • Travel

    Travel and ticketing on high-ticket authorisations

    High-ticket card authorisations carry interchange measured in basis points of large amounts. Routing to a lower-cost acquirer for a specific BIN range can shave double-digit basis points off the landed cost on those transactions.

  • PSP

    PSPs and ISVs reselling capacity

    PSPs reselling downstream pass the platform's fee structure to their merchants. Per-authorisation pricing with no monthly minimum lets the PSP scale into smaller-volume merchants without retainer drag.

Platform features

Capabilities behind the gateway transaction fee model

What the platform actually ships for fee handling — beyond the headline, the primitives that make the transparent stack work in production.

  • Pass-through interchange-plus

    Where the underlying acquirer supports interchange-plus pricing, the platform passes interchange and scheme fees through transparently — surfaced as separate lines on each reconciliation row.

  • Per-authorisation platform fee

    topropay's own fee is a single per-authorisation line — not a percentage embedded in a blended rate. Volume tiers apply; no monthly minimum.

  • Cost-weighted routing

    Per-transaction scoring on landed cost — interchange + scheme + acquirer markup for that specific BIN. Picks the cheapest available acquirer in the connected panel.

  • Approval-weighted routing

    Where the merchant prefers higher approval rate over lowest cost, the engine picks the highest-clearing route. Policy is dashboard-configurable per segment.

  • Composite routing

    Composite policies weight approval × cost × dispute risk into one score — most mature merchants converge on this after a few weeks of orchestration data.

  • Fee analytics in the dashboard

    Per-acquirer, per-BIN, per-scheme fee analytics in the operator portal; merchants A / B routing policies on real outcomes rather than spec sheets.

  • Audit-friendly reconciliation feed

    Every reconciliation row tags the acquirer ID, BIN, routing policy and the fee breakdown — interchange, scheme, acquirer, platform, optional risk fee.

  • No platform retainer

    No fixed monthly cost to keep the gateway open. Sandbox is unmetered. No per-environment fee.

  • Operator portal

    One dashboard for authorisations, refunds, disputes, chargebacks and fee analytics across every connected provider.

  • Sandbox parity

    Sandbox mirrors production fee reporting — merchants test routing policies and see the fee-breakdown shape before live volume.

  • PCI DSS Level 1 vault

    Card data captures into the vault before it touches any acquirer; vault tokens drive refunds and recurring.

  • Signed webhooks

    Replay-safe webhook delivery for state changes; SIEM-friendly out of the box.

Trust & compliance

Compliance posture and fee transparency

Every authorisation runs through a single audited environment, and every fee on the reconciliation row is its own line item.

PCI DSS Level 1
Annual on-site assessment plus quarterly ASV scans; sub-merchants inherit the posture.
Scheme programme tracking
Visa VDMP / VAMP and Mastercard ECP / EFMP thresholds tracked per acquirer with dashboard alerts.
Sanctions & AML alignment
Sanctions screening on onboarding; AML monitoring tuned per merchant vertical.
Fee transparency
Per-row fee breakdown on reconciliation; no hidden markups on interchange or scheme passes.
Data residency
Regional data-residency options for merchants under regulators that require it; EU-resident traffic stays in-region by default.
Licensed verticals only
Licensed gaming, regulated financial services and other compliance-bound verticals supported only where current operating licences exist. Grey and black-market verticals are out of scope regardless of integration shape.

Ready to see the stack

Transparent fees. Cost-weighted routing. Lowest landed cost per transaction.

A 30-minute pricing review walks through the connected acquirer panel relevant to your traffic, the routing policy that compresses your landed cost, and a sandbox that mirrors production fee reporting before any commercial commitment.

Book a pricing review Read the API docs

Frequently asked

Buyer questions about the fee payment gateway model

Questions buyers ask before committing — what "zero transaction fee" actually means, how the fee stack is broken out, what processor risk fees look like, and how cost-weighted routing differs from picking one cheap provider.

  1. 01

    What does topropay mean by fee payment gateway?

    Fee payment gateway on topropay is the transparent fee model — interchange and scheme fees pass through where the underlying acquirer supports it, the acquirer markup surfaces as a separate line, and topropay's per-authorisation platform fee is its own line. Merchants see the full stack rather than a blended rate, and routing policies let them optimise on landed cost.

  2. 02

    Is there really a lowest transaction fee payment gateway?

    There isn't one fixed lowest-fee gateway because the landed cost depends on the specific BIN, scheme and country pair — what's cheapest for a US debit BIN isn't cheapest for an EU credit BIN. The lowest transaction fee payment gateway behaviour shows up when the merchant runs cost-weighted routing across multiple connected acquirers — the engine picks the cheapest route per transaction rather than a single provider for all.

  3. 03

    Does topropay offer a payment gateway with zero transaction fee?

    No — and we'd be sceptical of anyone who claimed to. Card scheme interchange and scheme assessment fees apply on every card authorisation; 'zero transaction fee' offers usually mean a surcharge model that shifts the fee from the merchant to the buyer at checkout, which is regulated or prohibited in many markets. topropay doesn't pretend interchange goes away; we make it visible and route around the most expensive BINs where the merchant's policy allows.

  4. 04

    What does a typical payment gateway transaction look like end-to-end?

    A typical payment gateway transaction on topropay: the merchant POSTs to /v1/payments; the routing engine scores the request across the connected acquirer panel in under 200ms; the chosen acquirer sends the authorisation through the scheme to the issuer; the result (and any cascade) returns to the merchant inside the same request; signed webhooks fire on state changes; settlement and fee breakdown land on the reconciliation row.

  5. 05

    What is no fee payment processing in industry usage?

    No fee payment processing typically describes one of three things in industry usage: (a) surcharge models that shift the fee to the buyer (legal in some US states for credit, prohibited in EU for consumer payments); (b) cash-discount programmes that price card transactions higher than cash; (c) marketing claims that hide interchange inside a blended rate. None of those mean interchange doesn't exist — they restructure who pays it.

  6. 06

    What's the payment gateway transaction fee on topropay specifically?

    The payment gateway transaction fee on topropay is a per-authorisation platform fee on top of the underlying acquirer's interchange-plus pricing. Volume tiers apply; the specific number depends on the merchant's traffic shape, geography and vertical and is set during the commercial discussion. There's no monthly minimum and no per-environment fee.

  7. 07

    How does the platform handle payment gateway transaction charges across multiple acquirers?

    Payment gateway transaction charges across multiple acquirers normalise into one reconciliation feed. Every row tags the acquirer ID, BIN, scheme, the per-transaction interchange, scheme fee, acquirer markup, topropay's platform fee, and any optional risk fee. Finance sees the same shape regardless of which acquirer actually ran the authorisation.

  8. 08

    Can you walk through the payment gateway transaction flow at the API level?

    Payment gateway transaction flow at the API level: (1) merchant POST /v1/payments → (2) routing engine returns chosen acquirer + score → (3) acquirer authorisation message exchange via scheme → (4) result returns in the same HTTP response (or cascade and retry inside the same request on soft decline) → (5) signed webhook fires on state change → (6) capture POST when ready → (7) reconciliation row writes overnight with full fee breakdown. The merchant typically only writes code for steps 1, 5 and 6.

  9. 09

    What does payment gateway no transaction fee usually mean when buyers search for it?

    Payment gateway no transaction fee searches usually surface from merchants frustrated with blended pricing. The honest reading is: they're looking for transparency on the fee stack rather than literal zero fees. topropay's answer is interchange-plus pass-through and a clearly broken-out platform fee — not a 'no transaction fee' marketing claim that would hide the stack.

  10. 10

    What is gateway transaction fee in plain terms?

    Gateway transaction fee is the gateway's share of the per-authorisation cost. On a single-gateway model that's blended with the acquirer's markup; on topropay's orchestration model the platform fee is broken out separately from the underlying acquirer markup, so the merchant can see which layer charges what.

  11. 11

    What is the processor transaction risk fee?

    Processor transaction risk fee is a separate per-authorisation fee that some underlying acquirers / processors apply on high-risk-MCC or high-chargeback-band merchants. It's set by the underlying provider, not by topropay; where it applies, it surfaces as a transparent line on the reconciliation row rather than being absorbed into the markup. Merchants in lower-risk verticals don't see it at all.

  12. 12

    Are sandbox transactions billed?

    No. Sandbox is unmetered — merchants run as many test transactions as they need to build the integration, exercise routing scenarios, and validate the fee-breakdown shape against their own auditor. Production fees only apply to live tenants.

  13. 13

    How does cost-weighted routing differ from picking the cheapest provider once?

    Picking the cheapest provider once locks the merchant into one acquirer's appetite for all BINs; cost-weighted routing scores every authorisation against the connected panel and picks the cheapest route per transaction. The same merchant routes US debit to one acquirer and EU credit to another because the cost surface is different per BIN.

  14. 14

    What's the trade-off between cost-weighted and approval-weighted routing?

    Approval-weighted routing picks the route most likely to clear regardless of cost; cost-weighted picks the cheapest route regardless of approval lift. Composite routing weights both into one score and is what most mature merchants converge on. Switching between policies is a dashboard change, not a re-integration.

  15. 15

    How can a merchant evidence the fee transparency for their finance team?

    Daily reconciliation exports surface every authorisation with: acquirer ID, BIN, scheme, currency, country pair, routing policy used, interchange (where pass-through), scheme fee, acquirer markup, topropay platform fee, and any optional risk fee. Finance teams typically attach the export shape to their auditor pack as evidence of the per-transaction fee composition.

Related

Related on the topropay platform