Every collection surface · one merchant record

Collect payment from customer — every surface, one API, one ledger.

Hosted checkout, pay link, invoice pay, terminal, recurring, bank rail — six ways to collect payment from customer on the same merchant record. One vault, one dashboard, one dispute queue, one reconciliation feed.

Hostedcheckout Pay link/ QR Invoicepay flow Terminal/ SoftPOS Recurringbilling Bank railA2A merchant one record
Six surfaces · one merchant record · one API.
6+
collection surfaces on one merchant record
300+
payment methods reachable globally
1 API
across every surface and method
1 ledger
reconciliation across every receipt

Six ways to collect

Every surface a merchant uses to collect payment from customer

The platform ships six collection surfaces. Pick any mix, and add more as you grow. Every surface shares the same vault, dashboard and ledger.

  1. 01

    Hosted checkout

    A branded checkout page the merchant redirects the buyer to. PCI scope shrinks to SAQ A; time-to-live is days rather than weeks; card, wallet, BNPL and bank rails all render per market.

  2. 02

    Pay link (URL / QR)

    A one-off URL per amount or invoice — shared over email, WhatsApp, SMS or QR code. The buyer opens the link, pays through the same hosted surface, and the link self-destructs on success.

  3. 03

    Invoice pay flow

    Hosted pay links tied to an invoice ID, plus embedded pay-this-invoice fields the merchant can drop into their billing portal. Dunning, smart retries and auto-close on settlement come with the surface.

  4. 04

    In-person terminal & SoftPOS

    Card-present acceptance through licensed partner terminals plus SoftPOS / Tap-to-Phone. Vault tokens carry across so refunds work regardless of whether the sale was card-present or online.

  5. 05

    Recurring / subscription

    Card-on-file recurring, SEPA Direct Debit and recurring ACH — network tokens, account updaters and smart retries run server-side so renewals don't fall off the back of an expired card.

  6. 06

    Account-to-account bank rails

    SEPA, Open Banking (UK), ACH (US), PIX (BR), PayID (AU). Direct bank-rail acceptance for high-ticket transactions or markets where card interchange is unfavourable.

Key benefits

Why one platform beats one surface at a time

Most teams run collections on three stacks: a checkout, a billing tool, a terminal estate. Move them onto one platform and four clear gains show up.

  1. One integration for every surface

    Add a hosted checkout on Monday, a pay-link surface on Tuesday, an invoice pay flow on Wednesday, a terminal estate on Thursday — the merchant record is the same. New surfaces are configuration, not integration projects.

  2. One vault, tokens that travel

    A card tokenised on the hosted checkout is the same vault token used for a refund from the terminal, or a recurring renewal, or an invoice re-issue. No per-surface vault; no per-surface refund logic.

  3. One dashboard, one dispute queue

    Operators see every collection across every surface in one dashboard. Chargebacks, refunds and disputes route to one queue with evidence-pack templates per vertical.

  4. One reconciliation feed for finance

    Settlements from every connected acquirer normalise into one ledger tagged by surface, method, currency and provider. Finance imports the merged feed straight into the accounting system.

How the collection flow works

From surface selection to a closed reconciliation row in five steps

What happens after you pick a collection surface, step by step, up to the settled row finance sees in the ledger.

  1. 01

    Pick a surface (or several)

    Choose the collection surfaces relevant to the merchant's model — hosted checkout, pay link, invoice pay, terminal, recurring, bank rail. Any combination on the same merchant record.

  2. 02

    Present the surface to the buyer

    Redirect to the hosted checkout, share a pay link, attach it to an invoice, hand the terminal to the buyer, or schedule the next recurring cycle. The buyer sees the merchant's brand throughout.

  3. 03

    Route the authorisation

    The routing engine scores connected acquirers on BIN, scheme, currency, country pair and risk. Soft declines cascade to the next ranked lane inside the same authorisation.

  4. 04

    Tokenise into the vault

    Card data captures into the PCI DSS Level 1 vault; a vault token is issued back to the merchant. Refunds, retries and recurring flows all reference the token — no PAN on the merchant side.

  5. 05

    Settle, reconcile, close the loop

    Settlement files from each connected acquirer normalise into one ledger; signed webhooks fire on capture, settlement and dispute; the merchant's accounting system updates in real time.

Main use cases

Where merchants collect payment from customer across mixed surfaces

Six merchant shapes that pair two or three collection surfaces on the same platform — DTC, professional services, SaaS, retail, F&B and B2B invoicing.

  • DTC

    Cross-border DTC checkout

    A DTC brand collects payment through the hosted checkout with cards, wallets and BNPL surfaced per market. Recurring is added when the subscription plan launches — same merchant record.

  • Pro

    Professional services billing

    Consultancies and agencies send an invoice pay link per client; the buyer taps the link and pays by card or ACH. Reconciliation tags each receipt back to the originating invoice.

  • SaaS

    SaaS recurring subscriptions

    SaaS platforms collect payment from customer subscriptions via network-token recurring plus scheme account updaters — renewals don't fail on card re-issuance.

  • Retail

    Multi-store retail estates

    Head office collects payment through fixed counter terminals and SoftPOS on the sales floor; reconciliation rolls up by store and terminal into one ledger.

  • F&B

    Cafés, restaurants and pop-ups

    Tableside Tap-to-Phone plus a hosted online ordering link — same merchant taking card-present and card-not-present through the same platform.

  • B2B

    B2B invoicing across regions

    B2B contracts run against SEPA Direct Debit for EU buyers, ACH debits for US buyers, and hosted pay links for one-off invoices. One ledger, one dispute queue.

Platform features

Capabilities behind every collection surface

Twelve capabilities the platform ships once and reuses across every surface — from hosted-checkout primitives through to per-row reconciliation metadata.

  • Hosted checkout page

    Branded, per-currency, per-market method list; drops the merchant's PCI scope to SAQ A.

  • Hosted pay links (URL / QR)

    One-off URL per amount or invoice; self-destructs on success; QR variant for in-person or print use.

  • Embedded hosted fields

    Card-number, expiry and CVV render as iframes inside the merchant's own page; SAQ A-EP scope.

  • Low-level SDK

    Server SDK plus client primitives for merchants that want a bespoke checkout — vault tokenisation still runs through hosted iframes.

  • Partner terminals & SoftPOS

    In-person card acceptance via licensed partner terminals and Tap-to-Phone on NFC devices.

  • Recurring billing

    Card-on-file, SEPA SDD and recurring ACH — network tokens, updaters and smart retries.

  • Invoice pay flow

    Hosted pay links per invoice + embedded pay-this-invoice fields; dunning; auto-close on settlement.

  • Bank-rail acceptance

    SEPA, Bacs, ACH, PIX, PayID — bank rails in their native currencies through the same API.

  • Smart routing & cascade

    Per-BIN routing across connected acquirers; soft declines cascade inside the same authorisation.

  • PCI DSS Level 1 vault

    Card data captures into the platform vault before any acquirer sees it; PAN never lands on merchant systems.

  • Unified dispute queue

    One queue across every surface and provider; evidence-pack templates per vertical; automated representment for select scheme types.

  • One reconciliation feed

    Daily normalised feed across every connected acquirer, tagged by surface, method, currency, provider and merchant.

Industry relevance

Fit for licensed merchants across EU, UK, APAC and LATAM

topropay serves licensed merchants across Europe, the UK, APAC and LATAM, in both mainstream and licensed high-risk verticals. The same platform fits owner-run small businesses, mid-market retail, and large merchants that collect worldwide.

  • DTC & ecommerce
  • Professional services
  • SaaS & subscription
  • Retail & hospitality
  • B2B billing
  • Licensed gaming (where licensed)
  • Licensed financial services (where licensed)
  • Adult-content acceptance · out of scope
  • Unlicensed gambling · out of scope

Trust & compliance

Compliance posture across every collection surface

One audited environment underpins every collection; per-surface compliance details (PCI MPoC for SoftPOS, NACHA / SEPA mandate handling for bank rails) inherit from partner licences where relevant.

PCI DSS Level 1
Vault, switch and tokenisation are PCI DSS Level 1 service-provider components; sub-merchants inherit the posture across every collection surface.
SCA & PSD2
Selective EMV 3DS2 on the card path keeps European approval high on any collection surface without skipping the SCA bar.
PCI MPoC for SoftPOS
In-person collections via SoftPOS follow the PCI MPoC standard for accepting card-present transactions on commercial off-the-shelf devices.
NACHA / SEPA mandate handling
ACH and SEPA Direct Debit mandates captured and retained per scheme rules; mandate IDs travel with each collection.
Sanctions & AML alignment
Sanctions screening on onboarding; AML monitoring tuned per merchant vertical, volume and country mix.
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.

Ready to consolidate collections

Consolidate every way you collect payment from customer.

A 30-minute review covers the collection surfaces relevant to your model, the methods relevant to your buyers, and a sandbox to test against before any commercial commitment.

Frequently asked

Buyer questions about collect payment from customer flows

Definitions, per-surface mechanics, refunds, disputes, cross-border collections and the practicalities of running every collection surface through one platform.

  1. 01

    How do I collect payment from customer through topropay?

    You collect payment from customer on topropay through whichever surface fits the moment — hosted checkout for a website purchase, hosted pay link for an emailed or messaged request, invoice pay flow for a billed transaction, terminal or SoftPOS for card-present, recurring engine for subscriptions, or direct bank rails for account-to-account. All six run under one merchant record and one API.

  2. 02

    Do I have to pick one surface, or can I use several?

    Multiple surfaces run on the same merchant record. Most merchants collect payment from customer through two or three surfaces — hosted checkout + pay link + recurring is a common shape for SaaS; hosted checkout + terminal + invoice pay is common for retail with service billing on the side.

  3. 03

    What payment methods can I collect from a customer?

    Card (Visa, Mastercard, Amex, Discover, JCB, RuPay), wallets (Apple Pay, Google Pay, Click to Pay, regional wallets), BNPL (Klarna, Afterpay, Affirm, Clearpay), bank rails (SEPA, ACH, Bacs, PIX, iDEAL, Bancontact, PayID) and crypto rails (stablecoins, majors via licensed partner gateways) — 300+ methods across the connected panel.

  4. 04

    Is there a minimum ticket size to collect payment from customer?

    No platform-side minimum. In practice card-side economics work down to a few euros/dollars; below that, bank rails or wallets tend to be more efficient. Per-transaction pricing is interchange-plus or blended per the merchant's vertical and volume.

  5. 05

    How fast can I go live with the collection surface I need?

    Hosted checkout and hosted pay links go live in days — the dashboard supports both from day one after KYB. Terminals and SoftPOS follow the partner acquirer's underwriting timeline (typically 2–6 weeks). Recurring, bank rails and embedded fields deploy on the standard integration timeline.

  6. 06

    How does the buyer experience differ across surfaces?

    The buyer sees the merchant's brand throughout — same logo and colour on hosted checkout, hosted pay link and invoice pay surface. Terminals show the merchant name; recurring emails carry the merchant's template; bank-rail flows redirect to the buyer's bank through the standard scheme UI.

  7. 07

    How do refunds work across surfaces?

    Refunds run against the vault token issued at first collection. A card refunded from the terminal can be issued from the online back-office — and vice versa — because the token is shared. Operator-side refund controls require a reason code and log every event with actor identity and timestamp.

  8. 08

    How does the platform handle failed collection attempts?

    Soft declines cascade to the next ranked acquirer inside the same authorisation. Hard declines (insufficient funds, blocked card, closed account) don't cascade — they return to the merchant with a clear reason code so the merchant can trigger the appropriate follow-up flow (dunning email, retry a different day, ask the buyer for a different method).

  9. 09

    Can I collect payment from customers outside my home country?

    Yes. The connected acquirer panel covers EU, UK, APAC and LATAM as a baseline, with card BINs from most global geographies accepted. FX-aware acceptance (buyer's currency at checkout, merchant's currency at settlement) is available where the connected acquirer supports it — see the FX payment solutions surface for details.

  10. 10

    What compliance responsibilities does the merchant carry?

    The merchant carries the standard merchant-side responsibilities — KYC on their own customers where regulation requires it, terms and conditions on their own website, appropriate consumer-protection posture. topropay carries the PCI, scheme-programme, SCA and AML-monitoring responsibilities on the payments side.

  11. 11

    Can I collect payment from customer in one currency and settle in another?

    Yes. Multi-currency acceptance and settlement is a standard configuration — the buyer pays in their currency at checkout, the merchant settles in their treasury currency, and every settlement row is tagged with the applied FX rate for audit purposes.

  12. 12

    How does the platform handle chargebacks and disputes?

    Every chargeback across every surface lands in one dispute queue. Evidence-pack templates per vertical pre-fill scheme-required fields (transaction reference, delivery / fulfilment evidence, customer communications). Automated representment is available for select scheme types.

  13. 13

    Do I need to give topropay my own bank account?

    Yes — settlement lands in a bank account you nominate per acquirer relationship. Some merchants nominate a single treasury account; others split by region or by acquirer. The dashboard supports both.

  14. 14

    What kinds of businesses are NOT a good fit for topropay?

    Businesses operating in unlicensed gambling, adult content, grey-market goods or other compliance-bound verticals without the relevant operating licence aren't a good fit. Onboarding filters these out rather than letting volume start and face a sudden termination.

  15. 15

    Can I try it before signing a contract?

    Yes. Sandbox access covers the full API — hosted checkout, pay links, embedded fields, terminals in test mode, recurring, bank rails — and produces the same event stream and reconciliation shape as production. A 30-minute review confirms the surfaces relevant to your model before any commercial commitment.