Pay processor
topropay unifies pay processing across cards, the maestro payment system, account-to-account rails, text-to-pay, pay-by-ID and apps buy now pay later through a single integration. Smart routing picks the best acquirer per authorisation; reconciliation lands in one ledger; the buyer sees one checkout no matter which method runs underneath.
What it is
A traditional pay processor sells a single relationship: one acquirer, one method mix, one rate card, one ledger. That model works at small scale and breaks the moment a merchant goes cross-border, adds a new method or wants to compare outcomes. topropay rejects the single-relationship model outright. The platform is a pay processor in the sense that it owns the integration surface, the vault and the operator portal — but the rails behind it are multi-acquirer by default.
That means a Maestro authorisation can run through whichever connected acquirer scores best for the BIN and country; a buy now pay later request can route to the partner most likely to approve the buyer's profile; a text to pay reminder can drop a single-use link into the buyer's inbox without forcing a separate processor relationship. The merchant integrates once. The buyer sees one checkout. Finance reads one ledger. Engineering maintains one set of webhooks.
This page walks through how the pay processor surface is shaped — what the integration looks like, the methods carried, the routing model, the compliance posture and the practical questions buyers ask before they commit. Buzzwords like piq pay, pay id payment, pay per text and the maestro payment method are demystified in the FAQ rather than dropped into headings without context.
Key benefits
Four outcomes show up once the orchestration layer carries the integration instead of a single pay processor — whether the merchant runs five hundred transactions a day or five hundred per second.
Cards, wallets, account-to-account, BNPL, text-to-pay and pay-by-ID flows all route through the same unified API. Engineering integrates once; product can add or remove methods per market without a release. The shape of the request, the webhook contract and the reconciliation export look identical no matter which rail the authorisation eventually rides.
Every authorisation is scored across connected acquirers in under 200ms — BIN, scheme, currency, geography, fraud signal and historical approval all weighed against your own outcomes. Soft declines cascade to the next-best route inside the same request, so a temporary outage at one provider doesn't read as a checkout failure to the buyer.
Settlements, fees, refunds and chargebacks from every connected processor and method normalise into a single ledger keyed by vault tokens. Finance teams stop merging a CSV per provider, and disputes get resolved from one event timeline instead of three dashboards. Exports go out on a schedule in CSV, Parquet or signed event streams.
PCI DSS Level 1, SCA orchestration, regional data-residency options and PSD2-compliant 3DS2 challenge logic ship with the platform. Merchants integrate as sub-merchants and inherit the posture rather than building it themselves — useful both for fast-moving consumer brands and for the PSPs that resell topropay capacity downstream.
How it works
Integration takes days. Iteration after that — adding methods, tuning routing, swapping providers — happens from the dashboard, not from a release cycle.
Drop in the unified payments API, hosted checkout or embedded SDK. Existing acquirer relationships keep their contracts; topropay sits in front of them, not in their place. Sandboxes mirror production behaviour including routing and cascade logic.
From the dashboard, toggle the methods you want live per region — Maestro alongside Visa and Mastercard in Europe, PIX and OXXO in LATAM, PayID and BPAY in APAC, text-to-pay for service merchants. Routing policy switches between cost-optimised, approval-optimised or composite without a release.
Every authorisation runs through the routing engine. The best-fit pay processor wins the request; soft declines cascade to the next ranked route inside the same call. Network tokens and scheme account updaters keep recurring revenue alive through card re-issuance.
Each acquirer settles on its own schedule. topropay normalises currencies, fee structures and chargeback events into a single ledger so finance, treasury and ops read from one source. Method-specific metadata is preserved on every record.
Adjust routing weights, switch a provider on or off, layer in a new method — every change ships from the dashboard. Engineering stays out of the loop after day one, and the analytics view shows whether each change moved approval, cost or dispute rate.
Methods catalogue
Six method families that buyers ask about most often. Each one routes through the same pay processor surface as cards — same API contract, same vault, same reconciliation feed, same dispute model.
Buyers who pay by Maestro reach checkout through the same flow as Visa, Mastercard and local debit schemes. The maestro payment system is treated as a first-class rail inside the pay processor: 3DS2 selectively applied, network tokens issued where the scheme supports them, and refunds settled against the original maestro authorisation. Pay with Maestro works on hosted checkout, embedded fields and mobile SDKs without separate plumbing.
Service merchants — utilities, healthcare, field-service, SaaS — use the text-to-pay app and API hooks to send a one-tap pay link by SMS, WhatsApp or RCS. The buyer opens the link, picks a method, and the authorisation drops back into the same orchestration layer. Pay per text reminders are billable inside the dashboard, and text-to-pay companies that resell the capability get a tenant-scoped report per customer.
Pay ID payment in APAC, PayID lookups in Australia, account-name proxies in the UK and EU — all route through the same account-to-account model as SEPA, Bacs, ACH and PIX. The buyer enters an identifier rather than a card number; the bank does the routing; topropay handles the orchestration, reconciliation and refund logic on the merchant side.
Apps buy now pay later are surfaced at checkout as a first-class method — Klarna, Afterpay, Affirm, Scalapay, regional equivalents — with eligibility checked against the cart and buyer profile in real time. Settlement, refund and dispute flows for BNPL look the same as card flows in the reconciliation export, so finance does not maintain a parallel pipeline for instalment business.
Where merchants want exposure to buy now pay later crypto — stablecoin-collateralised instalments, on-chain repayment plans — topropay surfaces connected partners through the same checkout. The merchant settles in fiat; the underlying repayment plan lives on the partner's side. The pay processor stays the orchestration layer rather than a wallet custody platform.
Operators familiar with PIQ pay style routing recognise the orchestration shape: many acquirers per region, hot-swappable per method, with payouts running through the same engine as deposits. topropay supports licensed gaming and entertainment merchants in permitted jurisdictions — payouts, KYC handoff, dispute reconciliation — through the same pay processor surface used by retail and SaaS.
Platform features
What the platform actually ships. Engineering, finance and ops each have rows worth their attention.
One REST contract plus SDKs for JavaScript, server-side languages and mobile; same shape for every method.
Drop-in checkout for fast launch and hosted fields when you want full control of the surface and styling.
Per-transaction scoring across approval, cost, currency and dispute risk — measured against your own traffic.
Soft declines cascade through ranked routes inside one request; nothing leaks back to the buyer.
Card and Maestro PANs live in our vault, not your systems; refunds and recurring run on tokens.
Scheme network tokens and account updaters keep recurring revenue alive through card re-issuance events.
Selective authentication per authorisation; PSD2-compliant in Europe without challenging every shopper.
Settlements, fees, refunds and chargebacks normalise into one ledger; CSV, Parquet or signed event feeds.
Velocity rules, list management and a partner-agnostic fraud connector model — bring your own provider or ride ours.
One dashboard for authorisations, refunds, disputes and chargebacks across every connected provider and method.
Signed, normalised webhooks and an event stream that drops cleanly into your SIEM or warehouse.
A sandbox per environment that behaves the same as production, including routing and cascade scenarios.
Main use cases
The shape of the merchant traffic changes. The orchestration layer doesn't — same routing, same reconciliation, same vault.
Storefronts that sell across regions use topropay as a single pay processor for every market they're live in. Local methods surface at the checkout — Maestro and SEPA in Europe, PayID and BPAY in APAC, PIX and OXXO in LATAM — without per-country contracts. Settlement currency stays a policy choice, so a EUR-priced cart can settle in EUR even when the underlying rail is local.
Recurring billing on vault tokens, smart retry policies, account updaters and network tokens combine into a renewal recovery layer that's shared across every connected method. Pay processing for SaaS becomes a configuration choice — the engine that retries a failed card renewal also retries a failed Maestro one.
Platforms and PSPs inherit topropay's orchestration downstream. Their merchants ride the connected acquirer mix; split payments and seller payouts flow through the same layer; per-tenant analytics expose authorisation, cost and dispute rates without exposing the underlying provider list. Text-to-pay companies and pay-by-ID resellers use the same model.
Field-service, utilities, healthcare and education merchants use the text-to-pay app and pay-by-link generators to invoice customers without a checkout page. Each link is single-use, can be reused for partial payments, and lands the authorisation in the same orchestration layer. Pay per text billing is exposed in the dashboard for resellers.
Licensed gaming operators, ticketing platforms and live-event merchants run high-velocity deposits and payouts through the same pay processor surface. Hot-swappable acquirers per region keep approval high through scheme rule changes; payout latency stays predictable through the same routing engine that handles deposits.
Industry relevance
The orchestration model fits any vertical where method mix, geography and approval matter more than the brand of a single provider.
topropay works with licensed and regulated operators only. Gaming and entertainment merchants are onboarded where a current operating licence exists in a permitted jurisdiction; grey and black-market verticals are out of scope regardless of integration shape.
Trust & compliance
Pay processing on topropay runs through a single audited environment. Merchants integrate as sub-merchants and inherit the posture rather than building it themselves.
Ready to compare
A 30-minute review covers the methods that matter for your geography — Maestro, text-to-pay, pay-by-ID, BNPL — and routes a representative slice of your traffic in a sandbox before any commercial commitment.
Frequently asked
The questions buyers actually ask before they commit — covering Maestro, text-to-pay, pay-by-ID, BNPL, crypto rails, piq pay-style gaming flows and the practicalities of running multiple acquirers behind one integration.
topropay is both. The orchestration layer sits in front of connected acquirers, alternative methods and bank rails — but the merchant sees one pay processor, with one API contract, one vault, one reconciliation feed and one operator portal. The plurality lives behind the platform; the buyer-facing surface stays singular.
Pay processing for Maestro routes through connected European acquirers that hold scheme membership. Buyers who pay by Maestro see the maestro payment method at checkout alongside Visa and Mastercard; 3DS2 is applied selectively per authorisation; refunds settle against the original maestro authorisation. The maestro payment system is treated as a first-class rail, not a fallback, so pay with Maestro behaves identically to other card-scheme flows.
The text-to-pay service generates a single-use pay link, dispatches it over SMS, WhatsApp or RCS, and routes the resulting authorisation into the same orchestration layer used by hosted checkout. Pay per text usage is metered inside the dashboard. Text-to-pay companies that resell the capability to end-merchants get per-tenant reporting so they can rebill cleanly. A text to pay app SDK is exposed for merchants that want to embed the experience inside their own field-service or invoicing app.
Pay ID payment is an account-name proxy used in APAC bank rails — PayID in Australia, equivalents elsewhere. Buyers enter an identifier rather than a bank account number; the bank resolves it to the underlying account; settlement runs over the local instant-payment rail. topropay treats pay-by-ID as account-to-account, alongside SEPA, Bacs, ACH and PIX, with the same orchestration, reconciliation and refund behaviour as card flows.
Yes. Apps buy now pay later — Klarna, Afterpay, Affirm, Scalapay and regional equivalents — surface at checkout with eligibility checked in real time against the cart and buyer profile. For buy now pay later crypto, connected partners offer stablecoin-collateralised instalments; the merchant settles in fiat while the repayment plan lives on the partner's side. Settlement and dispute reporting normalise into the same ledger as card flows.
A single-acquirer setup forces every maestro authorisation through one route, even when a different connected acquirer has materially better approval in a given country. The maestro payment system inside topropay is multi-acquirer by default — the routing engine scores connected providers per authorisation and picks the best fit. The merchant sees one integration; the buyer sees one checkout; the cascade absorbs declines that a single-acquirer setup would surface as failures.
PIQ pay is a routing model familiar in licensed gaming and entertainment — many acquirers, hot-swappable per method and region. topropay is not PIQ pay, but it serves the same orchestration shape for licensed operators in permitted jurisdictions. Deposits and payouts run through the same engine; method mix is configurable per region; reconciliation is unified across the lot.
Yes. There's no platform retainer or volume minimum. A small business can integrate once and reach the same connected acquirer mix as enterprise tenants, with the same routing engine and reconciliation feed. Pay processing fees pass through transparently, and lighter tiers exist for support and onboarding so small teams aren't paying for procurement hand-holding they don't need.
Most merchants are live on hosted checkout in days and on the unified API in a few weeks. Migrating from a single pay processor incumbent typically takes a quarter end-to-end including procurement, sandbox parity testing and a staged traffic ramp. The platform supports running old and new processors in parallel during cutover so revenue never lives on a single integration during the migration window.
Live in Europe, the UK, APAC and LATAM with selective coverage in the Middle East and North America. The connected provider list per region is exposed in the merchant dashboard rather than published as a marketing page — the live state changes by week, and the dashboard reflects status, latency and approval analytics per connected provider for your contracted regions.
Routing is policy-driven and provider-agnostic. Swapping out a connected pay processor for a different one is a dashboard change, not a re-integration. Vault tokens are portable inside the platform; reporting stays consistent through provider swaps; and contract terms are negotiated separately from the integration shape, so commercial leverage stays with the merchant.
The connected text to pay companies, BNPL providers, acquirers and account-to-account partners surface inside the merchant dashboard — scoped to your contracted region and method mix. The list rotates faster than a marketing page can keep up with, so dashboard state is authoritative. Procurement teams get an exportable PDF snapshot under NDA when needed.