Types of e-payment system

Types of e payment system, unified under one orchestration API.

topropay's orchestration layer exposes every major payment-system type — card, bank rail, wallet, BNPL, crypto and recurring — behind one unified API. Each type is just a setting on the same platform. You don't pick a different SDK per category.

Book a coverage review Read the API docs
topropay Card Bank rail Wallet BNPL Crypto Recurring six categories · one orchestration · one API
Same root · six child types · same API surface.
6+
categories under one API
300+
methods reachable globally
60+
connected acquirers and PSPs
1 ledger
across every type

Key categories

The six core types of payment system on topropay

Six categories cover most e-commerce, recurring and B2B payment flows. Each one is exposed through the same API. Methods within a category stay dashboard-configurable per market.

  1. 01

    Card payments

    Credit, debit, prepaid and corporate cards across Visa, Mastercard, Amex, Discover, JCB and RuPay. The dominant rail in most markets; routed across multiple connected acquirers per BIN, scheme and country pair.

  2. 02

    Bank-rail payments (ACH / SEPA / Open Banking)

    ACH (US), SEPA (EU), Bacs and Open Banking (UK), PIX (BR), Interac (CA), PayID and OSKO (AU). ach payment types include credits, debits, same-day, and recurring debits with NACHA mandate handling.

  3. 03

    Wallets and pay-sheets

    Apple Pay, Google Pay, Click to Pay, Alipay+, WeChat Pay, GrabPay and regional wallets. Tokenised handoff with no PAN on the merchant side; same authorisation engine as card on the back.

  4. 04

    BNPL (buy-now-pay-later)

    Klarna, Afterpay, Affirm, Clearpay and Atome plug into the same authorise endpoint as card. Settlement and refund flows match the card-side shape; per-market availability is dashboard-configurable.

  5. 05

    Crypto rails

    Stablecoins (USDC, USDT, DAI), majors (BTC, ETH, SOL) and L2 networks delivered through licensed partner crypto gateways. Optional conversion-on-receipt keeps treasury fiat-only.

  6. 06

    Recurring / scheduled

    Card-on-file recurring, SEPA Direct Debit, recurring ACH, PIX-Recorrência where supported. Cycle scheduling, smart retries, network tokens and account updaters run server-side on the platform.

Gateway shapes

Different types of payment gateway integration on the platform

Three integration shapes share the same back-end. The choice comes down to PCI scope and how much UI control you want. The routing, vault and reconciliation stay identical across all three.

Hosted page

Drop-in redirect or iframe

The merchant's PCI scope shrinks to SAQ A. Fastest path to live; minimal engineering work; brandable through dashboard CSS overrides.

Hosted fields (embedded)

Inline iframes inside the merchant's checkout

Card-number, expiry and CVV fields render as hosted iframes on the merchant's own page. PCI scope sits at SAQ A-EP; UI control is fully merchant-side.

Low-level SDK

Full control of the surface

Server SDK plus client primitives let the merchant build a bespoke checkout. Vault tokenisation still runs through the hosted-field tokeniser; PAN data never lands on the merchant origin.

Fraud taxonomy

Types of payment frauds and how the platform defends against each

Six recurring fraud vectors and the controls that address each. Fraud isn't one shape; the defences match the attack pattern.

Card-not-present (CNP) fraud
Stolen or compromised card credentials used in an online transaction. The card vault and selective 3DS2 / SCA orchestration reduce CNP fraud exposure; per-BIN velocity rules and list management add another layer.
Friendly / first-party fraud
Cardholder disputes a legitimate charge. The unified dispute queue, evidence-pack templates per vertical and automated representment for select scheme types fight back; vault-token-based receipts simplify evidence.
Account takeover (ATO)
Attacker takes over a customer's account and authorises payments. Device-fingerprinting signals feed into the routing engine; selective step-up authentication intercepts high-risk authorisations.
Refund / triangulation fraud
Attacker uses a refund flow as a money-out channel. Operator-side refund controls require justification and log every refund event with actor identity, reason code and timestamp.
Synthetic-identity fraud
Fabricated identity used to onboard or transact. KYB / KYC on onboarding plus sanctions screening at the platform level keep synthetic identities out of the merchant base.
Chargeback abuse & ratio inflation
Excessive chargebacks pushing the merchant over scheme programme thresholds (VDMP / VAMP / ECP). The dashboard surfaces position vs limit per acquirer and routing weights can rotate around at-risk providers.

Main use cases

Where mixing types of online payment system earns its keep

Six merchant shapes that combine multiple payment-system types — DTC, SaaS, marketplaces, travel, B2B and PSPs.

  • DTC

    Cross-border DTC mixing multiple types

    A DTC brand surfaces cards, wallets, regional bank rails and BNPL on the same checkout — different types of payment systems for ecommerce per market, one integration and one reconciliation.

  • SaaS

    Subscriptions on card + bank rail

    Network-token recurring on cards plus SEPA Direct Debit on EU customers. Both run through the same recurring engine; merchant doesn't fork billing per rail.

  • Plat

    Marketplaces mixing rails per seller

    Some sellers receive card payouts, others SEPA or stablecoin. The orchestration layer handles the per-seller policy; reconciliation rolls up by rail and by seller in one feed.

  • Travel

    Travel and ticketing across types

    Card for default checkout, bank rail for high-ticket bookings (lower interchange), wallet for mobile, crypto for the small but growing crypto-native segment.

  • B2B

    B2B invoicing across types

    Card on small tickets, bank rail (ACH / SEPA SDD) on recurring B2B contracts, stablecoin for cross-border counterparties — all under one contract.

  • PSP

    PSPs reselling all types downstream

    Resellers inherit the full type catalogue and route their merchants across it. The PSP keeps the relationship and pricing; the platform handles the per-type message exchange.

Platform features

Capabilities shared across every payment-system type

The platform ships these once and reuses them across card, ACH, wallet, BNPL, crypto and recurring. They are the primitives that make the whole type catalogue feel like one product.

  • Unified API across all types

    One REST contract for card, bank rail, wallet, BNPL, crypto and recurring; SDKs for web, mobile and server.

  • Hosted, embedded and SDK surfaces

    Pick the integration shape that matches the merchant's PCI / UI constraints; same back-end for all three.

  • Smart routing engine

    Per-transaction scoring on BIN, scheme, currency, country pair and risk — ranked routes per authorisation across the connected panel.

  • Cascade & retry

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

  • PCI DSS Level 1 vault

    Card data captures into the platform vault before it touches any provider; vault tokens drive refunds, retries and recurring.

  • Network tokens & updaters

    Network tokens by default for card; scheme updaters keep saved cards alive across re-issuance.

  • 3DS2 / SCA orchestration

    Selective challenges per transaction — PSD2-compliant in Europe without breaking conversion.

  • ACH / SEPA mandate handling

    NACHA / SEPA mandate IDs captured and retained per scheme rules; recurring debits on bank rails share the same engine as card-on-file recurring.

  • Crypto via partner gateways

    Stablecoins, majors and L2 networks via licensed partner crypto gateways inside the same API as fiat.

  • Unified dispute & chargeback queue

    One queue across providers; evidence-pack templates per vertical; automated representment for select scheme types.

  • Unified reconciliation

    Settlements, fees, refunds and chargebacks across every type normalised into one ledger; daily exports tagged by type, provider and routing policy.

  • Risk & fraud controls

    Velocity rules, list management, partner-agnostic fraud-engine connectors and operator-side refund controls layered on top of routing.

Trust & compliance

Compliance posture across the type catalogue

One audited environment underpins every type. Merchants inherit the relevant posture per type rather than carrying separate certifications themselves.

PCI DSS Level 1
Annual on-site assessment plus quarterly ASV scans; sub-merchants inherit the posture across every payment-system type.
SCA & PSD2
Selective 3DS2 on the authorisation path keeps approval high in Europe without skipping the compliance bar.
Bank-rail mandate posture
NACHA authorisations for ACH, SEPA mandate IDs for SEPA Direct Debit; captured and retained per scheme rules.
Sanctions & AML alignment
Sanctions screening on onboarding; AML monitoring tuned per merchant vertical, volume and type mix.
Crypto partner-gateway compliance
Crypto rails delivered through licensed partner gateways with VASP / MiCA-relevant authorisations; AML / KYC inherited.
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 regardless of type.

Ready to pick the mix

Pick the payment-system types that fit your business.

A 30-minute coverage review covers the categories relevant to your traffic — card, ACH, wallet, BNPL, crypto, recurring — the routing policies that fit, and a sandbox to test against before any commercial commitment.

Book a coverage review Read the API docs

Frequently asked

Buyer questions about types of e payment system on topropay

Questions buyers ask before committing. They cover definitions, ACH types and fraud taxonomy. They also cover the healthcare-context mix-up and how it works to run multiple types through one API.

  1. 01

    What does the platform mean by types of e payment system?

    Types of e payment system on topropay covers the major rails the unified API exposes: card, bank rail (ACH / SEPA / Open Banking / PIX / PayID and others), wallet, BNPL, crypto (via partner gateways) and recurring / scheduled. Each is a configuration of the same API rather than a separate integration.

  2. 02

    How many types of payment gateway shapes does topropay support?

    Types of payment gateway shapes on the platform are three: a hosted page (redirect or iframe), embedded hosted fields (card-number, expiry, CVV rendered as iframes inside the merchant's checkout), and a low-level SDK for full surface control. All three share the same back-end and reconciliation feed.

  3. 03

    What are the different types of payment gateway in industry usage?

    Different types of payment gateway in industry usage break down by integration shape (hosted vs embedded vs SDK), by connectivity (single-provider vs orchestration), and by vertical (mainstream vs high-risk vs crypto). topropay sits in the orchestration shape — one API in front of many gateway-shaped connections.

  4. 04

    How do the different types of payment system compare on the platform?

    Different types of payment system on the platform compare on settlement timing, dispute model and per-transaction cost. Card settles T+1 to T+30 with full scheme chargeback rights; bank rails settle on the rail's own calendar with rail-specific recall processes; crypto settles in minutes with no chargeback window. The platform absorbs the per-rail differences and presents a consistent API.

  5. 05

    What are the typical types of payment system shapes for an ecommerce merchant?

    Typical types of payment system shapes for an ecommerce merchant combine cards (default), wallets (mobile dominance), BNPL (cart uplift on higher tickets), and one or two regional bank rails per market the merchant sells into. Crypto is added by merchants serving crypto-native buyers or wanting borderless stablecoin settlement.

  6. 06

    What ach payment types are supported?

    ACH payment types supported include consumer ACH debits (WEB, TEL, PPD), business ACH debits (CCD), ACH credits for payouts, and same-day ACH where the underlying processor supports it. NACHA mandate evidence is captured at sign-up; R-code-aware retries handle NSF / R01 / R03 / R04 returns according to the merchant's configured policy.

  7. 07

    What types of payment frauds does the platform help defend against?

    Types of payment frauds the platform helps defend against include card-not-present (CNP) fraud, friendly / first-party fraud, account takeover (ATO), refund / triangulation fraud, synthetic-identity fraud at onboarding, and chargeback ratio abuse. The PCI L1 vault, selective 3DS2, unified dispute queue, operator-side refund controls and KYB / KYC onboarding flow each address different fraud vectors.

  8. 08

    Are there different types of payment systems for ecommerce specifically?

    Different types of payment systems for ecommerce on topropay surface as a configuration of the unified API: hosted checkout with card + wallet + BNPL as default, embedded hosted-fields for merchants who want their own UI around the form, and SDK for fully bespoke checkouts. The wider 'payment system' includes the routing, vault and reconciliation behind the surface.

  9. 09

    What types of online payment system are typically the highest-volume on the platform?

    Types of online payment system that drive the highest volume are card and wallet across most markets; bank rails (SEPA, iDEAL, PIX) dominate in their respective home markets; BNPL contributes notably on higher-ticket commerce; crypto is a growing but still minority share. The mix shifts as the merchant's buyer base expands geographically.

  10. 10

    What are the different types of e payment system from a technical perspective?

    Different types of e payment system from a technical perspective break down by message format (card uses ISO 8583 / 20022, bank rails use the rail's own scheme, crypto uses on-chain RPC), settlement timing (T+1 to T+30 for card, minutes for crypto, variable for bank rails) and dispute model (chargebacks for card, recalls for bank rails, no unilateral chargebacks for crypto). topropay's API exposes them through a consistent shape.

  11. 11

    Some searches mention '3 types of payment systems in healthcare' — does that apply to topropay?

    That phrasing refers to the US healthcare insurance / claim adjudication context, where the 'three types' typically describe insurer-side reimbursement models (fee-for-service, capitation, bundled payment) rather than payment-rail categories. That is a completely different domain from payments-industry e-payment systems, and topropay does not operate in healthcare claim adjudication or insurance billing. The 'types' framing on this page is the payments-industry one — card, bank rail, wallet, BNPL, crypto, recurring.

  12. 12

    What about 'different types of payment systems in healthcare' as a search query?

    Different types of payment systems in healthcare overlap with the same healthcare-context confusion. A US healthcare merchant that wants to accept card payments for services can integrate topropay for the PCI / payment-rail side; the healthcare merchant's own systems remain responsible for HIPAA-covered PHI handling. topropay is NOT a HIPAA-covered entity. PCI and HIPAA are separate regulatory domains.

  13. 13

    Can a single merchant run all payment-system types simultaneously?

    Yes. Service categories on the platform (card, ACH, crypto, facilitation, subscriber) are independent toggles. A merchant can run any combination — card + ACH + crypto, or card + BNPL + wallet, or all of the above. Adding a category later is a dashboard step, not an integration project.

  14. 14

    How does the platform handle type-specific compliance differences?

    Type-specific compliance is wrapped on the platform side: PCI DSS for card, NACHA / SEPA mandate handling for bank rails, MiCA / VASP authorisations for crypto via partner gateways. Merchants inherit the posture per type rather than carrying separate certifications themselves.

  15. 15

    What's the best way to compare payment-system types for a given merchant?

    The best comparison is on actual production traffic. topropay's sandbox supports the full type matrix, and parallel-running with an existing provider during migration lets the merchant measure approval, cost and dispute outcomes per type before absorbing the rest of the volume.

Related

Related on the topropay platform