Payment merchant relationships — direct MID or sub-merchant, one API.

1. Onboarding

   Skip the per-acquirer queue

   One onboarding flow with topropay replaces a queue of direct-acquirer applications. KYC, KYB, vertical-fit and risk underwriting happen once on the platform side; the merchant integrates as a sub-merchant and inherits the underlying acquirer relationships.

2. Reach

   Every connected provider behind one merchant relationship

   The payment merchant relationship spans the connected acquirer, PSP and method portfolio — cards, wallets, bank rails, BNPL and (via partner gateways) crypto — without separate contracts per provider. New methods light up as configuration in the dashboard.

3. Approvals

   Smart routing on every authorisation

   Per-transaction scoring runs every authorisation through the route most likely to clear at the lowest landed cost. Soft declines cascade to the next ranked acquirer inside the same request — the buyer never sees a per-provider retry loop.

4. Operations

   One operator portal, one reconciliation feed

   Authorisations, refunds, disputes and chargebacks across every connected provider land in one operator portal. Settlements, fees and chargebacks normalise into one ledger — the merchant team learns one tool, not one per acquirer.

• Retail & DTC

  Storefronts and headless commerce

• Subscriptions & SaaS

  Renewals and account-updater wiring

• Marketplaces

  Split payments and seller payouts

• Travel & hospitality

  Staged captures, multi-currency

• Ticketing & events

  Peak-load resilience

• Financial services

  Regulated wallets, top-ups, payouts

• Nonprofits & fundraising

  Recurring donor flows

• Licensed gaming

  Operators with current licences only

The platform works with licensed and regulated operators only. Grey- and black-market verticals — unlicensed gambling, adult, illicit substances, fraud-adjacent business models — are out of scope regardless of integration shape.

PCI DSS Level 1

Annual on-site assessment, quarterly ASV scans. Sub-merchants inherit the posture; direct-MID merchants integrate against the same audited environment.

SCA & PSD2

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

Scheme programmes

Visa VDMP / VAMP / VFMP and Mastercard ECP / EFMP thresholds tracked per merchant; dashboard surfaces position vs limit.

Sanctions & AML

Sanctions screening on onboarding; AML monitoring tuned per vertical, volume and region mix.

Underwriting transparency

Decision rationale and any per-acquirer constraints surfaced during onboarding — no surprise rejections after go-live.

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 regardless of integration shape.

1. 01

   What does topropay mean by a payment merchant relationship?

   A payment merchant relationship on topropay is the umbrella for how a merchant transacts through the platform — direct MID, sub-merchant or a hybrid. It spans onboarding, the unified payments API, the operator portal and the reconciliation feed across every connected acquirer, PSP and method.

2. 02

   Is the payment merchant gateway a single product or many?

   From the merchant's perspective it is one product — one API, one operator portal, one reconciliation feed. From the routing engine's perspective each connected acquirer is a lane the engine scores per transaction. The payment merchant gateway behaviour you integrate against is identical regardless of how many lanes the engine fans out to.

3. 03

   What is the difference between an online payment merchant account and the sub-merchant model?

   An online payment merchant account is held directly with each underlying acquirer — the merchant owns the underwriting and the settlement-to-bank relationship per provider. The sub-merchant model lets the merchant integrate as a sub-merchant on topropay's acquiring contracts; one onboarding, one settlement schedule, no per-provider underwriting paperwork. Both are valid; the right choice depends on volume, vertical and contractual preference.

4. 04

   How can I accept credit card payment without merchant account contracts in place?

   Accept credit card payment without merchant account contracts via the sub-merchant model: one onboarding with topropay replaces a queue of direct applications. The platform's acquiring relationships absorb the volume; settlement flows from the aggregator to your bank on a fixed cycle. Migrate to a direct-MID model later if the economics or contractual position justify it.

5. 05

   What do payment merchant services cover beyond card acceptance?

   Payment merchant services on the platform cover card, ACH and SEPA bank-rail acceptance, subscriber / recurring services, payment facilitation (for marketplaces and platforms), crypto acceptance via partner gateways, the operator dashboard, KYC / KYB, the reconciliation feed and the dispute queue. The categories are independent toggles on the merchant contract.

6. 06

   What does payment merchant account onboarding actually look like?

   Payment merchant account onboarding through topropay is one application: business identity verification (KYB), ultimate beneficial owner (UBO) verification, vertical / MCC declaration, expected volume and a website / app review. The platform then routes the application through the relevant connected acquirers; the merchant sees one consolidated decision, not a queue of provider-specific responses.

7. 07

   How are online payment merchant services priced?

   Online payment merchant services on topropay carry no platform retainer — pricing is per-authorisation on top of the underlying provider economics. Interchange and scheme fees pass through where the underlying provider supports it; the platform's fee is a separate line on the invoice. Enterprise volume earns negotiated improvements on the platform side.

8. 08

   Which card payment merchant services are typically active?

   Card payment merchant services active on the platform include Visa, Mastercard, Amex, Discover, JCB and RuPay acceptance across the connected acquirer panel — with multi-acquirer routing, network tokens, scheme updaters and selective 3DS2 / SCA. Per-BIN routing weights are configurable from the dashboard.

9. 09

   How do merchant gateway providers compare to an orchestration layer like topropay?

   Merchant gateway providers typically expose their own API, their own SDK and their own webhook stream — the merchant integrates per-provider. An orchestration layer like topropay collapses many providers into one API surface with routing and cascade between them. The merchant trades a slightly larger up-front integration for years of optionality across the connected provider panel.

10. 10

    What does merchant gateway services include in this model?

    Merchant gateway services in the orchestration model include the API surface (hosted page, embedded fields, low-level SDK), the vault, the routing engine, the cascade behaviour, scheme-updater wiring, the dispute queue, the operator portal and the reconciliation feed. Each is callable independently — the merchant can use the hosted page on day one and switch to embedded fields when ready.

11. 11

    Is there a single online merchant gateway behind the platform or many?

    Functionally there is one online merchant gateway from the merchant's perspective — the unified API. Internally the platform routes across many — every connected acquirer's gateway is a lane the routing engine can pick per transaction. The merchant doesn't manage which lane wins; the routing engine does.

12. 12

    How do credit card payment merchant services behave on the smart routing engine?

    Credit card payment merchant services run through the same routing engine as every other rail. Each authorisation is scored against the merchant's own outcomes (approval rate, dispute rate, landed cost) and the route most likely to clear at the lowest landed cost wins. Soft declines cascade to the next ranked acquirer inside the same request.

13. 13

    What happens to merchant operations during a connected provider's outage?

    During a connected provider's outage the routing engine rotates traffic to the next ranked provider in the relevant set. The merchant's checkout stays available; the only effect on the merchant side is a shift in the per-acquirer authorisation mix that day. The cascade behaviour absorbs single-provider outages without the merchant needing to fail over manually.

14. 14

    Can a merchant run the direct-MID and sub-merchant models in parallel?

    Yes — direct MID and sub-merchant are not mutually exclusive. A merchant can hold direct relationships with some acquirers while riding the platform's MIDs for others (often used to extend reach into markets where the merchant lacks a direct relationship). The platform handles both shapes inside the same operator portal and reconciliation feed.

15. 15

    How does the platform handle dispute management across the payment-merchant set?

    Dispute management across the payment-merchant set runs through one unified queue regardless of underlying acquirer. Evidence-pack templates per vertical, automated representment for select case types and a clear timeline per dispute let merchant ops handle disputes from one surface instead of switching between acquirer-specific consoles.