Processing online payment

Processing online payment, card and ACH, on the same routed pipeline.

topropay runs every online authorisation — card or ACH — through one routed pipeline. Smart routing per BIN, cascade on soft declines, vault tokenisation, signed webhooks and a single reconciliation feed across rails. Built for licensed merchants only, with explicit handling for regulated gaming, betting and gambling.

Book a processing review Explore the platform
topropay · /processing.log
  1. 14:02:01 auth pay_4f8a · EUR 189.00 · routed acq_eu_03 · 184ms
  2. 14:02:02 soft pay_4f8b · USD 42.00 · acq_us_01 · cascading…
  3. 14:02:02 auth pay_4f8b · USD 42.00 · routed acq_us_02 · cleared
  4. 14:02:03 ach pay_4f8c · USD 18.50 · ach_partner_a · pending
  5. 14:02:04 auth pay_4f8d · GBP 64.00 · routed acq_uk_01 · 152ms
  6. 14:02:05 cap pay_4f8a · captured · ledger row q3-09421
6 events · 1 cascade · 0 hard declines
Cards + ACH
on the same processing engine
<200ms
routing decision
Cascade
across acquirers on soft decline
1
ledger across rails

Key benefits

Why orchestrated payment processing online wins on card and ACH

Four outcomes that show up consistently once card and ACH authorisations share the same routed processing pipeline.

  1. Coverage

    Card and ACH on one processing engine

    Credit card processing online payment and ach payment processing online both run through the same unified API. Vault tokens, signed webhooks and event semantics are identical across rails — the merchant's billing system doesn't fork per rail.

  2. Approvals

    Smart routing per BIN, scheme and country pair

    Every card authorisation runs through the routing engine; the route with the lowest landed cost at the highest approval likelihood wins. Soft declines cascade to the next ranked acquirer inside the same request — the buyer never sees a per-provider retry.

  3. Operations

    One ledger across card, ACH and disputes

    Settlements, fees, refunds and chargebacks from card and ACH normalise into one ledger keyed off vault tokens. Per-rail filters in the dashboard surface where the next routing tweak earns its keep.

  4. Onboarding

    Sub-merchant or direct-MID path

    Online businesses can integrate as sub-merchants on topropay's acquirer contracts — no per-acquirer underwriting — or layer the platform on top of an existing direct-MID stack. The integration code is identical either way.

How it works

Five stages from authorise to one normalised ledger row

What happens between the merchant POST and the reconciliation export. Five stages, one round-trip per authorisation.

  1. 01

    Authorise

    Single POST to /v1/payments with amount, currency and method (card or ACH). The routing engine scores the request in under 200ms.

  2. 02

    Route

    BIN, scheme, currency, country pair and risk decide which connected acquirer runs the authorisation. Per-merchant routing policy applies (approval-, cost- or composite-weighted).

  3. 03

    Cascade

    Soft declines fail over to the next ranked acquirer inside the same authorisation. Hard declines and risk-based rejections do not cascade.

  4. 04

    Capture & confirm

    Authorisation result lands in a signed webhook event — authorised / declined / captured / refunded — with the routed acquirer ID and route score attached.

  5. 05

    Reconcile

    Settlement, fees, refund and chargeback data normalise into one ledger; per-rail and per-acquirer analytics in the dashboard.

Main use cases

Where payment processing for online store, business, B2B and recurring earns its keep

Six mainstream merchant shapes that share the same processing engine. Licensed gaming, betting and gambling are covered in the dedicated section below.

  • Store

    Payment processing for online store and DTC retail

    Online retailers running cards, wallets, ACH (for US debits) and local APMs across markets — one integration, one reconciliation, conversion-optimised method ordering at checkout.

  • Subs

    Subscriptions and recurring billing

    Card and ACH recurring on vault tokens, network-token-by-default for cards, smart retries on declines, dunning surfaces wired into the same processing engine.

  • Biz

    Payment processing for online business at scale

    High-volume online businesses route across the connected acquirer panel rather than depending on one. Routing weights are tuned against your own traffic — not generic benchmarks.

  • B2B

    B2B invoicing and supplier flows

    Card and ACH on one API for invoice-driven flows; multi-currency capture and partial captures for staged contractual settlements.

  • Travel

    Travel, ticketing and high-ticket retail

    Staged captures, partial refunds, multi-currency and dispute analytics handle the long lifecycle of a high-ticket order from one timeline.

  • ACH

    ACH-led merchant flows

    Utility-style ACH debits with NACHA mandate handling, R-code-aware retries and the same operator portal as card traffic — useful where the ACH economics beat card for low-ticket recurring.

Licensed verticals

Payment processing for online gambling, gaming and betting — licensed operators only

Licensed gaming, betting and gambling operators in permitted jurisdictions are supported through the same processing engine as mainstream merchants. The compliance bar — what's in scope, what isn't — is explicit and non-negotiable.

In scope
  • Licensed online gaming operators in permitted jurisdictions with current operating licences and full KYC / AML / responsible-gaming controls.
  • Licensed online betting and sports-betting operators where the operator holds the relevant local licence.
  • Licensed online gambling brands with regulator-approved methods and operator-side responsible-gaming workflows.
  • Operator-specific 3DS / risk policies layered on top of the standard routing engine — no surfacing of methods the operator's licence does not permit in that market.
Out of scope
  • Unlicensed gambling, grey-market betting or operators in jurisdictions without a clear regulatory framework for the vertical.
  • Operators who request 'cash-out' or wallet flows that bypass their KYC and responsible-gaming controls.
  • Methods or routes not explicitly permitted by the underlying acquirer for the gaming MCC.
  • Any vertical operating outside the platform's licensed-and-regulated posture, regardless of integration shape.

Platform features

Capabilities behind the processing pipeline

What the platform actually ships for card and ACH authorisation, capture, refund and reconciliation — the primitives that make the pipeline feel like infrastructure.

  • Unified payments API

    One REST surface for card and ACH; SDKs for web, mobile and server.

  • Smart routing engine

    Per-transaction scoring on BIN, scheme, currency and country pair.

  • Cascade & retry

    Soft declines cascade to the next ranked acquirer inside the same authorisation.

  • PCI DSS Level 1 vault

    Card data captures before merchant origin; refunds, retries and recurring on vault tokens.

  • Network tokens & updaters

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

  • ACH NACHA handling

    Mandate evidence captured at sign-up; R-code-aware retry calendar; ACH debits and credits on the same API.

  • 3DS2 & SCA orchestration

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

  • Webhook event stream

    Signed, replay-safe webhooks for every state change across card and ACH.

  • Operator portal

    One dashboard for authorisations, refunds, disputes and chargebacks across rails.

  • Sandbox parity

    Sandbox that mirrors production — including routing, cascade, ACH R-codes and webhook replay.

Cost structure

Cheapest payment processing online — what 'cheap' actually means

Five lines that explain how the cost stacks. The headline: no platform retainer, no sandbox fee, no minimum monthly — pass-through underlying-provider economics, plus a per-authorisation platform fee.

  1. 01

    No platform retainer

    There's no fixed monthly fee for the processing engine — pricing is per authorisation on top of underlying acquirer / rail economics. The 'cheapest payment processing online' framing maps directly onto cost-weighted routing: every authorisation runs through the route with the lowest landed cost.

  2. 02

    Interchange-plus on cards

    Card authorisations carry interchange and scheme fees as pass-through where the underlying acquirer supports it; the platform fee is a separate line on the invoice.

  3. 03

    Flat per-transaction on ACH

    ACH payment processing online runs at a flat per-transaction price — useful for low-ticket recurring debits where card economics don't fit.

  4. 04

    No minimum monthly

    No platform minimum — small-business merchants don't pay for capacity they don't use, and growing volume earns negotiated improvements on the platform side automatically.

  5. 05

    Sandbox is unmetered

    Pre-production testing doesn't add to the bill.

Trust & compliance

Compliance posture for the processing pipeline

Every authorisation runs through one audited environment. Merchants inherit posture rather than carrying separate certifications per provider.

PCI DSS Level 1
Annual on-site assessment, quarterly ASV scans, sub-merchants inherit the posture.
Scheme programmes
Visa VDMP / VAMP / VFMP and Mastercard ECP / EFMP thresholds tracked per connected acquirer.
ACH NACHA evidence
Mandate authorisations captured at sign-up; retained per scheme rules; surfaceable for audit.
SCA & PSD2
Selective 3DS2 on card authorisations to keep approvals high in Europe without skipping compliance.
Signed events
HMAC-signed webhooks with rotation; idempotency keys on mutation endpoints; SIEM-friendly event stream.
Licensed verticals only
Licensed gaming, regulated financial services and similar compliance-bound merchants supported only where current operating licences exist. Grey and black-market verticals are out of scope regardless of integration shape.

Ready to process

Route card and ACH through one processing pipeline.

A 30-minute processing review covers the rails relevant to your traffic, the routing policies that fit, the licensed-vertical posture if relevant, and a sandbox to test against before any commercial commitment.

Book a processing review Read the API docs

Frequently asked

Buyer questions about processing online payment on topropay

Questions buyers ask before committing — covering card and ACH specifics, licensed verticals, cost framing, latency, disputes and sandbox parity.

  1. 01

    What does 'processing online payment' actually mean on topropay?

    Processing online payment on topropay is the end-to-end authorisation pipeline: the API call from your back-end, the routing decision across the connected acquirer panel, the cascade on soft declines, the capture, the refund flow, the dispute queue and the reconciliation feed. Card and ACH both run through the same pipeline with rail-specific metadata where it differs.

  2. 02

    How does payment processing online differ from a card-only gateway?

    Payment processing online on topropay covers cards plus ACH plus regional APMs (SEPA, iDEAL, BLIK, PIX, OXXO, PayID) and crypto via partner gateways — all behind one API. A card-only gateway exposes only the card surface; the orchestration model collapses many rails into one integration.

  3. 03

    Is the platform a good fit for payment processing for online business at scale?

    Yes — payment processing for online business at scale is the platform's design centre. Routing across many acquirers, cascade across soft declines, network tokens, smart retries on recurring traffic, unified reconciliation. Volume-band pricing kicks in automatically; no separate enterprise SKU to negotiate.

  4. 04

    How does credit card processing online payment work end-to-end?

    Credit card processing online payment runs the authorisation through the routing engine, picks an acquirer per the merchant's routing policy, cascades on soft decline, captures into vault tokens, fires a signed webhook on every state change and rolls the settlement into the unified ledger. Network tokens are on by default for major schemes; refunds and partial captures run on vault tokens.

  5. 05

    Does the platform support payment processing for online gambling?

    Yes — payment processing for online gambling is supported only for licensed operators in permitted jurisdictions, with current operating licences and full KYC / AML / responsible-gaming controls. Unlicensed gambling and grey-market operators are out of scope regardless of integration shape. The In-scope / Out-of-scope block above lists the posture.

  6. 06

    What about ach payment processing online for US-domiciled merchants?

    ACH payment processing online is first-class — same routing engine and reconciliation as card, plus rail-specific NACHA mandate handling and R-code-aware retries. US merchants typically pair ACH (low-ticket recurring) with card (high-ticket one-off) on the same integration.

  7. 07

    Is there explicit payment processing online gaming support?

    Payment processing online gaming is supported for licensed gaming operators in permitted jurisdictions only. Routing, cascading, vault tokenisation and reconciliation behave the same way as for any other merchant; operator-specific risk rules and method bias sit on top. Unlicensed gaming operators are not onboarded.

  8. 08

    What about payment processing for online betting specifically?

    Payment processing for online betting follows the same rule: licensed operators only, in permitted jurisdictions, with KYC / AML / responsible-gaming controls in place. The platform's role is the processing pipeline — the operator's role is running the betting product itself in compliance with their licence.

  9. 09

    How does payment processing for online store integrations look?

    Payment processing for online store integrations usually means dropping the hosted payment page into the storefront (Shopify-like, WooCommerce-like or a custom stack), wiring one webhook handler, and configuring the methods per market. Most teams reach live in days; the SDK route is for teams that want full control of the checkout UI.

  10. 10

    Is there really cheapest payment processing online on the platform?

    Cheapest payment processing online on topropay maps directly onto cost-weighted routing: every authorisation runs through the route with the lowest landed cost (interchange-plus pass-through + platform fee). The trade-off vs approval-weighted routing is fractionally lower approval; for many merchant segments cost-weighting still wins on net revenue. The policy is dashboard-configurable per segment.

  11. 11

    How fast is the typical processing decision?

    The routing engine returns a decision in under 200ms for the vast majority of authorisations; cascade behaviour adds the underlying acquirer's response time, still typically well inside a checkout's per-transaction budget. Sandbox tests against the same latency profile as production.

  12. 12

    What kinds of disputes and chargebacks does the platform handle?

    Disputes and chargebacks across every connected acquirer surface in a single dispute queue, with evidence-pack templates per scheme (Visa, Mastercard) and per vertical. Operator-side workflows handle representment, refund-to-resolve and write-off — auditable per actor and per timestamp.

  13. 13

    Is there a separate sandbox for testing online-payment processing?

    Yes — a per-environment sandbox that mirrors production endpoint surface, signed webhooks (with rotating test secrets), and deterministic helpers for triggering specific outcomes (decline reasons, 3DS challenge / frictionless / decline, ACH R-codes, webhook replay). The error model and shape are identical to production.

  14. 14

    Can the same processing engine handle multi-currency and cross-border traffic?

    Yes. Settlement currency is a policy choice per merchant per market; cross-border traffic is routed through the regionally-correct acquirer to keep interchange and dispute outcomes local. Multi-currency capture and FX-on-receipt policies sit alongside the standard processing flow.

  15. 15

    How does the platform handle PSD2 / SCA for European processing traffic?

    European processing traffic carries selective 3DS2 / SCA on the authorisation path — challenges fire when the risk profile or transaction type requires them; otherwise traffic flows frictionlessly. PSD2-compliant without forcing every shopper through a step-up.

Related

Related on the topropay platform