Processing business

Processing business, two ways: payments for your business, or a payments business for your customers.

topropay's orchestration layer fits the merchant who needs payment processing for their business — and the PSP or ISV building a processing business of their own on aggregated capacity. One unified API, smart routing across every connected provider, and one reconciliation feed across the lot.

Book a processing review Explore the platform
Merchant PSP / ISV topropay Day 1 Week 1 Month 1
Two starting tracks. One orchestration layer. One scaling curve.

The short version

What "processing business" actually means in payments

The phrase covers two very different shapes. The first: a business that needs payment processing to operate — an online retailer, a subscription company, a marketplace, a travel operator. The second: the business of providing payment processing — a PSP, an ISV embedding payments into its product, an aggregator reselling capacity downstream. Both shapes hit the same problem at scale: one provider is rarely enough, and running several without a unifying layer turns into a per-acquirer integration backlog.

topropay sits between the two by orchestrating a connected portfolio of acquirers, processors and methods behind a single unified API. A merchant integrates once and reaches every connection; a PSP or ISV wraps that orchestration with its own product and resells it under its brand. The set of providers stays the same in both scenarios — what changes is which side of the API surface you sit on.

The rest of this page walks through who the platform fits, the benefits that show up consistently across the merchant base, how a typical online payment processing business setup unfolds across the first month, the use cases that recur most often, and how the capability set differs by tier — SMB, enterprise and PSP — so you can see exactly where your own processing business lands.

Who this page is for

Three flavours of payment processing business that fit the platform

The shape of the orchestration is the same; the framing differs by where you sit. Pick the one that matches your situation — the rest of the page builds on it.

  • Merchant

    Run a business that needs payment processing

    DTC, subscriptions, marketplaces, travel, services — any business taking payments online or in-app at scale.

  • PSP / ISV

    Build a processing business on aggregated capacity

    Software vendors and PSPs reselling payment processing downstream to their own merchants under their brand.

  • Migration

    Move off a single-provider stack

    Existing acquirer or processor in place — you keep it; the orchestration layer adds parallel capacity.

Key benefits

What changes when payment processing for a business is orchestrated

Five outcomes that show up consistently once orchestration sits in front of the provider stack — for merchants and for PSPs running a processing business of their own.

  1. One integration in front of every connected processor

    A payment processing business model that depends on a single provider hits a ceiling fast. topropay puts an entire provider portfolio behind one unified API; new acquirers and methods become configuration, not engineering.

  2. Routing that fights for every authorisation

    Per-transaction scoring picks the route most likely to clear at the lowest landed cost. Soft declines cascade to the next ranked provider inside the same request, so an outage at one connection doesn't take a day of revenue with it.

  3. Reconciliation that closes the month from one export

    Settlements, fees, refunds and chargebacks across every connected provider normalise into one ledger. Finance closes the month from a single source of truth instead of a CSV-per-provider merge.

  4. Operational leverage for a digital payment processing business

    Operator portal, signed events, sandbox parity and per-tenant reporting let a small ops team supervise a multi-provider stack. The shape of the platform scales with the business, not against it.

  5. PSP-grade resell for software vendors

    ISVs and PSPs running a processing business of their own ride topropay's aggregated capacity, then resell it under their brand. Per-tenant routing, reporting and dispute queues sit inside the same product surface.

How it works

From signup to a tuned online payment processing business setup, in three time slices

The rollout follows the same arc whether you're a merchant or a PSP. Day 1 is integration, Week 1 is live traffic, Month 1 is optimisation.

  1. Day 1 Integration
    • Sandbox keys issued; SDK / hosted checkout drops in.
    • Initial KYC + sub-merchant onboarding kicked off in parallel.
    • First test authorisations against connected acquirers.
  2. Week 1 Live traffic
    • Production routing policies live — approval, cost or composite.
    • Cascade configured per acquirer's soft-decline surface.
    • Webhook subscriptions wired into your SIEM / data warehouse.
  3. Month 1 Optimisation
    • BIN-level analytics highlight where to re-weight routing.
    • Method mix tuned per market based on real conversion data.
    • Disputes flowing through one unified queue with evidence-pack templates.

Main use cases

Where an orchestrated digital payment processing business earns its keep

Four scenarios that recur across the merchant base — each ends up running the same orchestration product with a different policy on top.

  • DTC

    Online retailer scaling across markets

    A merchant that started on one PSP needs a payment processing business setup that covers SEPA, iDEAL, BLIK, PIX and OXXO without per-country plug-ins. The orchestration layer absorbs the method list and the multi-acquirer routing in one product.

  • Subs

    Subscription business with renewal recovery as a KPI

    Network tokens, scheme updaters, smart retry policies and per-acquirer routing combine to keep MRR from leaking on a card re-issuance event. The lift over a single-provider stack shows up in the renewal cohort.

  • ISV

    ISV embedding payments into an existing product

    An ISV building online payment processing for business inside its own SaaS needs a per-tenant model with isolated reporting, dispute queues and routing policies. The platform exposes that as a multi-merchant product the ISV resells under its brand.

  • Travel

    Travel / ticketing operator with staged captures

    Staged captures, partial refunds, multi-currency capture and dispute analytics handle the long lifecycle of a travel order from one timeline — across multiple acquirers, not one per country.

Platform features

Capability matrix across an SMB, an enterprise and a PSP

What ships with the platform across three typical sizes of processing business. The base orchestration is the same; the wrap-around features differ by tier.

Capability SMBEnterprisePSP / ISV
Unified payments API ✓ ✓ ✓
Hosted checkout + SDK ✓ ✓ ✓
Smart routing engine default policies custom policies per-tenant policies
Cascade & retry ✓ ✓ ✓
Network tokens & updaters ✓ ✓ ✓
Multi-acquirer connectivity ✓ ✓ ✓
Per-tenant reporting — ✓ ✓
Dispute queue & evidence packs ✓ ✓ ✓
Signed webhooks & event stream ✓ ✓ ✓
White-label checkout — ✓ ✓
Reseller billing & payout splits — — ✓

Trust & compliance

Compliance posture inherited by every processing business on the platform

One audited environment, applied across every connected provider. Merchants integrate as sub-merchants and inherit the posture rather than carrying separate certifications.

  1. PCI DSS Level 1

    Service-provider posture validated annually on-site; quarterly ASV scans run on the platform cycle and inherited by sub-merchants.

  2. Sub-merchant model

    Merchants integrate as sub-merchants on the platform's acquirer contracts; one onboarding replaces per-acquirer applications.

  3. 3DS2 & SCA

    Selective challenges on the authorisation path — PSD2-compliant in Europe without breaking conversion.

  4. Sanctions & AML

    Sanctions screening on onboarding; AML monitoring scaled to merchant vertical and processing volume.

  5. Licensed verticals only

    Licensed gaming, regulated financial services and other compliance-bound verticals supported where current operating licences exist. Grey and black-market verticals are out of scope.

Ready to scope a setup

Map your business onto the orchestration layer in 30 minutes.

A 30-minute review walks through the methods and acquirers relevant for your business, whether the sub-merchant or PSP path fits, and a sandbox to test against before any commercial commitment.

Book a processing review Read the API docs

Frequently asked

Buyer questions about running payment processing inside a business

What buyers ask before committing — definitions, integration, pricing, fit for different business shapes and the path from sandbox to live traffic.

  1. What does a 'processing business' usually mean in payments?

    Processing business is a slightly ambiguous phrase. It can mean a business that needs payment processing to operate, or the business of providing payment processing — running a PSP, ISV or similar. topropay supports both shapes through the same orchestration layer: merchants integrate as sub-merchants; PSPs and ISVs ride aggregated capacity and resell it under their brand.

  2. What does a payment processing business setup look like on topropay?

    A payment processing business setup is one unified API call from the merchant's checkout into topropay, then routing across the connected provider portfolio. The merchant doesn't run per-acquirer SDKs or per-provider reconciliation; the platform absorbs that work and exposes one operator portal across the lot.

  3. How does online payment processing for business compare with a single-provider stack?

    Online payment processing for business through orchestration adds parallel acquirer capacity. The single-provider stack hits a ceiling at one underwriting appetite, one rate card and one chargeback ratio. The orchestration model spreads load across the connected portfolio and turns 'which provider' into 'what's the right routing policy'.

  4. Is the platform suitable as a payment processing business model for an ISV?

    Yes. An ISV building a payment processing business model into an existing SaaS gets a per-tenant view — isolated reporting, dispute queues and routing policies per merchant — that the ISV can resell under its brand. The ISV doesn't have to underwrite acquirers itself; it rides the platform's relationships and adds its own product layer on top.

  5. How is a digital payment processing business different from a card-only setup?

    A digital payment processing business treats card as one of many rails. Wallets, BNPL, bank rails and (via partner gateways) crypto all participate in the same checkout, the same vault and the same reconciliation feed. topropay's hosted checkout surfaces them per market without a separate plug-in per method.

  6. What does the online payment processing business onboarding flow look like?

    An online payment processing business onboarding flow is one KYC + underwriting cycle with topropay rather than a queue of per-acquirer applications. The platform handles the per-acquirer paperwork on your behalf. Most merchants get to live traffic in days for a hosted checkout, weeks for a fully embedded build.

  7. Do you publish a price list?

    Pricing is contract-specific because the underlying provider economics differ by vertical, region, ticket size and volume. There's no platform retainer; merchants pay per authorisation on top of the underlying provider rates, with interchange and scheme fees passed through where the underlying provider supports it.

  8. Can a merchant keep their existing acquirer?

    Yes. The orchestration layer doesn't require replacing existing acquirers; it adds parallel capacity on the connected portfolio and routes per-transaction across whichever providers are configured. Existing acquirers can stay in place and pick up the share of traffic the routing engine sends their way.

  9. What kind of reporting does a PSP / ISV get?

    Per-tenant reporting — authorisations, settlements, fees, refunds, chargebacks — for every merchant the PSP resells to, with the option to expose the same reporting to those merchants through the PSP's own surface. Reseller billing and payout-split features sit on top of the same data model.

  10. Which verticals are out of scope?

    Licensed and regulated verticals are supported where current operating licences exist. Grey- and black-market verticals — unlicensed gambling, illicit substances, fraud-adjacent business models — are out of scope regardless of integration shape.

  11. How does the routing engine react to peak load?

    Routing engine throughput is provisioned ahead of seasonal peaks. The cascade naturally absorbs spikes that hit one provider harder than another by re-routing to the next ranked acquirer inside the same request. Redundant acquiring zones keep authorisation available through outages on a single connection.

  12. How quickly can a merchant move from sandbox to live processing business traffic?

    Most merchants reach live traffic in days for a hosted checkout, weeks for a fully embedded build. The slowest step is usually onboarding (KYC, underwriting) rather than engineering — the API surface is small enough to integrate in a sprint. Switching on new methods or new acquirers afterwards is a dashboard change rather than a release, so the live integration shape continues to evolve without engineering involvement after day one.

  13. What does the data model look like behind an online payment processing business setup?

    Behind any online payment processing business setup on topropay, every authorisation is a record that carries the vault token, the routed acquirer ID, the BIN, the scheme, the currency, the country pair, the risk score and the cascade history. Refunds, captures, chargebacks and reconciliation rows all link back to that authorisation record. Finance, ops and engineering all read the same data model from different angles — finance via the ledger export, ops via the dispute queue, engineering via the event stream.

  14. What's the cleanest path for a merchant whose payment processing business model is shifting from retail into subscriptions?

    A payment processing business model shifting from one-off retail into subscriptions usually trips on three things at once: renewal recovery, dunning policy, and the routing change that comes with recurring authorisations. Network tokens, scheme updaters and per-segment routing policies absorb each of those without re-platforming. The hosted checkout supports tokenised initial and follow-on authorisations behind the same surface, so the migration happens behind the scenes rather than at the checkout layer.

  15. How does the platform handle reporting for an online payment processing business with many merchants underneath it?

    For an online payment processing business with downstream merchants — a PSP or ISV — the reporting model is per-tenant by default. Each merchant's authorisations, settlements, refunds and disputes are scoped to their tenant; the parent organisation rolls them up for billing, support and risk monitoring. Reseller billing and payout splits sit on top of the same per-tenant data, so the PSP doesn't need a separate ledger system to operate.

Related

Related on the topropay platform