Payment processor company

The payment processor company question, solved by routing instead of procurement.

topropay's orchestration layer puts several connected processors and gateways behind one unified API. Pick the right route per authorisation instead of picking one vendor for everything — across cards, wallets, bank rails and cryptocurrencies payments, in one console.

Book a processor review Explore the platform
Processor scorecard A1 82% approval 1.42% cost EU A2 88% approval 1.55% cost UK A3 79% approval 1.20% cost US A4 85% approval 1.65% cost APAC topropay routes
Four processors, one routing layer.
  • 1 integration to maintain
  • many processor relationships behind it
  • <200ms routing decision
  • 0 lock-in per provider

The short version

Three things actually worth evaluating in a payment processor company

Marketing pages rank processors by features. Operating teams rank them by the three numbers below — and orchestration turns those numbers into a routing policy instead of a procurement decision.

  1. Approval

    Authorisation rate on your traffic

    The number that actually moves the P&L. Headline rate cards rarely correlate with approval performance on a specific merchant's BIN mix and geography. Measured per acquirer behind a payment processor company, not per logo.

  2. Cost

    Landed cost per authorisation

    Interchange + scheme + processor fee + downgrade risk. The cheapest sticker price is often expensive once downgrades, dispute fees and FX show up. Composite-cost routing makes this a number, not a guess.

  3. Posture

    Compliance and resilience by design

    PCI DSS Level 1 service-provider posture, SCA orchestration, signed event delivery, redundant acquiring zones — the things that don't appear on a marketing page but determine whether the relationship survives audits, outages and peaks.

Key benefits

Why a merchant processor strategy is a portfolio, not a logo

Four outcomes consistently show up when a merchant moves from a single-processor stack to an orchestration layer in front of several connected providers.

  1. 01

    Replace 'choose one processor' with 'route across several'

    Picking a single payment processor company forces every merchant decision through one underwriting appetite, one rate card and one chargeback ratio. Orchestration runs each authorisation through the route most likely to clear at the lowest landed cost across the connected set.

  2. 02

    Test new processors without re-integration

    Adding a new connected payment processor and payment gateway to the panel is a platform-side configuration, not a merchant-side build. A new processor can run shadow traffic, then a percentage, then a primary lane — without redeploying the checkout.

  3. 03

    Make sticky relationships negotiable

    A merchant tied to a single processor by sunk integration cost has limited renegotiation leverage. With orchestration, the integration is permanent and the processor relationships are commercial — leverage moves from vendor to merchant on every contract renewal.

  4. 04

    Centralise reporting across every relationship

    One reconciliation feed across every connected processor, every acquirer, every method. Finance closes the month from a single export, regardless of how many processor logos appear on the back-office side.

How it works

A checklist for replacing a payment processor and payment gateway stack

Six concrete stages between the merchant deciding to consolidate and a live cascade in production. Engineering work concentrates at stages 2 and 3; ops work simplifies afterwards.

  1. Map

    Map current processor relationships and their performance

    Approval, cost, dispute and downgrade analytics per existing provider — the baseline for what orchestration is replacing.

  2. Connect

    Drop in the unified API or hosted checkout

    Same surface as today's processor SDK; the back end abstracts the processor surface so you never call individual providers.

  3. Onboard

    Sub-merchant onboarding to the connected panel

    Single underwriting flow on topropay's side covers the relevant processor and acquirer relationships in parallel.

  4. Configure

    Per-segment routing and method mix

    Pick the routing policy — approval-weighted, cost-weighted or composite — per market and per segment. Method availability is dashboard-configurable.

  5. Route

    Live cascade across the panel

    Every authorisation runs through the routing engine; soft declines cascade to the next-best provider in the same request.

  6. Improve

    Tune from the dashboard, not a release

    Routing weights, method mix and risk thresholds are operations changes, not engineering changes.

Main use cases

Merchant shapes that benefit most from a multi-processor portfolio

Six common shapes. Same product surface; different routing policy on top.

  • 01

    Mid-market e-commerce

    Storefronts that have outgrown a single processor and need cross-border coverage, currency choice and a stable checkout surface that doesn't change when the processor mix changes.

  • 02

    Multi-tenant platforms and PSPs

    Platforms whose own merchants need multi-provider depth; the platform itself integrates once and exposes a curated subset of the processor panel downstream.

  • 03

    Subscriptions and recurring

    Renewal recovery improves when retries can target a different processor than the original authorisation. The orchestration layer makes that routine, not a per-provider script.

  • 04

    Travel and ticketing

    Long order lifecycles, partial captures and multi-currency settlement benefit from multi-processor routing tuned to dispute calendars and refund windows per scheme.

  • 05

    Subscription crypto and treasury merchants

    Merchants accepting cryptocurrencies payments alongside fiat ride the same orchestration layer — a cryptocurrencies payment processor surface is one method tile among many.

  • 06

    Licensed high-risk verticals

    Verticals where a high risk merchant processor is needed (subscriptions, travel, ticketing, nutraceuticals, licensed gaming) — multi-processor routing with chargeback-aware policies tuned per MCC.

Platform features

What the platform ships behind the gateway payment processor surface

Ten capabilities that show up most often in buyer-side checklists when a payment processor company is being evaluated, replaced or supplemented.

  • Unified payments API

    One REST contract across every connected processor and gateway; SDKs for web, mobile and server.

  • Routing engine

    Per-transaction scoring on BIN, scheme, currency, country and risk — ranked routes per authorisation.

  • Cascade & retry

    Soft declines cascade to the next ranked processor inside the same authorisation; nothing leaks back to the buyer.

  • Secure payment processor posture

    PCI DSS Level 1 vault; refunds, retries and recurring on vault tokens regardless of underlying provider.

  • Network tokens & SCA

    Network tokens by default, scheme updaters across processors, selective 3DS2 / SCA on the auth path.

  • Crypto rails

    Cryptocurrencies payment processor support via licensed partner gateways — same API as cards.

  • Unified reconciliation

    Settlements, fees, refunds and chargebacks normalised across every connected processor and acquirer.

  • Dispute & chargeback queue

    One queue across processors, evidence-pack templates per vertical, automated representment for select case types.

  • Operator portal

    One dashboard for authorisations, refunds, disputes and chargebacks across every connected processor.

  • Webhooks & events

    Signed, normalised events into your SIEM or warehouse; per-event-type subscription model.

Trust & compliance

Compliance posture across the connected processor set

Every connected processor and gateway runs inside the platform's audited environment. Sub-merchants inherit the posture rather than carrying separate certifications per provider.

  1. 01

    PCI DSS Level 1

    Service-provider posture validated annually on-site; quarterly ASV scans run on the platform cycle.

  2. 02

    Scheme programme tracking

    Visa VDMP / VAMP / VFMP and Mastercard ECP / EFMP thresholds tracked per processor relationship.

  3. 03

    SCA & PSD2

    Selective 3DS2 challenges on the authorisation path keep approvals high without skipping the compliance bar.

  4. 04

    Sanctions & AML alignment

    Sanctions screening on onboarding; AML monitoring tuned per processor's appetite and per merchant vertical.

  5. 05

    Licensed verticals only

    Licensed gaming, regulated financial services and other compliance-bound merchants are supported only where current operating licences exist. Grey and black-market verticals — including unlicensed adult — are out of scope regardless of integration shape.

Ready to compare processors

Stop picking a processor — pick the routing policy instead.

A 45-minute processor review walks through the connected panel for your geographies and method mix, the routing policies that suit your traffic, and the sub-merchant onboarding path. No long-form questionnaire required up front.

Book a processor review Read the API docs

Frequently asked

Buyer questions about choosing a payment processor company

What buyers ask before committing — definitions, the gateway-vs-processor distinction, crypto and high-risk fit, and the practicalities of replacing a single-processor stack with an orchestrated one.

  • How is topropay different from a single payment processor company?

    A single payment processor company runs every authorisation through one underwriting appetite, one rate card and one chargeback ratio. topropay is an orchestration layer in front of several connected payment processors, gateways and acquirers — every authorisation runs through the route most likely to clear at the lowest landed cost, against your own traffic. The merchant integrates once and decides commercially which processors to route to.

  • What's the difference between a payment gateway and payment processor?

    A payment gateway is the technology surface that accepts the authorisation message and forwards it; a payment processor handles the message flow with the schemes and the acquiring bank. The terms blur in marketing copy — many vendors are both. topropay sits one layer above and orchestrates across many such gateways and processors through a single API.

  • Is topropay itself a payment gateway and payment processor, then?

    Functionally yes — from your code's perspective the platform exposes both gateway and processor surfaces. Strictly, it's an orchestration layer in front of multiple licensed gateways and processors. The merchant doesn't integrate with the underlying providers directly; topropay abstracts them behind one unified API.

  • Does that mean I can replace my payment gateway payment processor stack with one integration?

    That's the usual outcome. A payment gateway payment processor stack with several direct integrations collapses into one topropay integration; the gateway and processor relationships behind it stay (or get replaced) without merchant-side rework. The integration is permanent, the provider relationships are commercial.

  • How does payment gateway processor selection actually happen on each transaction?

    Payment gateway processor selection happens in the routing engine — per BIN, per scheme, per currency, per country, per risk segment, in under 200ms. The route most likely to clear at the lowest landed cost wins; soft declines cascade to the next ranked route inside the same request. The selection is a policy choice, not a vendor lock-in.

  • What is a payment processor gateway in this context?

    Payment processor gateway is the combined surface that authorises, captures and settles card payments under a specific processor's licence. topropay connects to several of those and treats each as a routable lane. From your integration's perspective it's one API; from the routing engine's perspective each payment processor gateway is a separate ranked option.

  • What if I'm asking about the difference between a payment processor and payment gateway specifically?

    Payment processor and payment gateway refer to two layers of the same flow: the gateway captures and forwards the authorisation, the processor moves the message through the schemes and acquirer. In modern stacks they're often one entity. topropay abstracts both, so the merchant only ever speaks to one API regardless of how the labels split internally at the underlying provider.

  • What does a secure payment processor mean inside the platform?

    A secure payment processor inside topropay is a connected provider that passes the platform's vetting on PCI DSS posture, scheme programme standing and operational resilience. Beyond that, the platform wraps every authorisation in its own PCI DSS Level 1 vault, signed events and selective 3DS2 — so the security posture is consistent across processors rather than dependent on each provider's own surface.

  • Can topropay connect to a cryptocurrencies payment processor as well as fiat?

    Yes. A cryptocurrencies payment processor is delivered through licensed partner gateways and surfaces in the same unified API as fiat. From the merchant's perspective the integration shape is identical; the underlying rail moves stablecoins, majors or L2 transactions instead of cards, with optional conversion-on-receipt to fiat.

  • Is there a difference between a payment processor crypto setup and the fiat path?

    A payment processor crypto setup carries an on-chain confirmation calendar and no chargeback window, but operates inside the same authorisation, vault and reconciliation model. Refunds happen on-chain when the merchant chooses to issue them; disputes don't happen unilaterally the way card disputes do. Same dashboard, different rail.

  • What about cryptocurrencies payment volume — is it reconciled separately?

    Cryptocurrencies payment volume reconciles into the same ledger as fiat, with the on-chain reference, conversion-on-receipt fee and settlement currency surfaced as additional columns. Finance closes the month from one export regardless of which rail moved each authorisation.

  • How does this compare to a single gateway processor model?

    A single gateway processor model concentrates the merchant's authorisation risk in one provider and one underwriting appetite. The orchestration layer replaces that concentration with a portfolio: the same merchant runs traffic across multiple providers, with the routing engine picking per transaction. Volume can shift between processors without re-platforming.

  • Can topropay serve as the merchant processor for a sub-merchant model?

    Yes — the sub-merchant model is one of the two integration paths. The merchant integrates once with topropay; underwriting and KYC happen platform-side with the underlying providers; settlement flows on a fixed schedule. The other path keeps direct MIDs in place and uses topropay as orchestration only.

  • What about a high risk merchant processor setup for licensed verticals?

    A high risk merchant processor setup runs through topropay's high-risk routing policies: chargeback-aware acquirer selection, per-MCC method bias and dispute-evidence-pack templates per scheme. Licensed gaming, subscriptions, travel, ticketing, nutraceuticals and similar verticals are typical workloads.

  • Do you support a payment processor adult workload?

    A payment processor adult workload is supported only where the merchant operates a licensed and regulated adult business with full age-verification, KYC and AML controls in place. Unlicensed adult content, illegal categories and content that violates scheme rules are explicitly out of scope. For licensed mainstream adult merchants, routing and chargeback-aware policies apply the same way they do for other licensed high-risk verticals.

Related

Related on the topropay platform