Payment integration

Payment integration that ships in days — one API, every provider, every surface.

topropay's payment integration platform sits in front of every connected acquirer, PSP and method. Website, ERP, form-builder and crypto integration patterns share the same back-end; the merchant integrates once and turns the relevant pieces on from the dashboard.

Book an integration review Read the API docs
Merchant stack Hosted Embedded SDK topropay unified API Card A Card B ACH PIX iDEAL USDC
One integration. Many providers behind it.
Days
to live hosted-page integration
1 API
across every method and provider
SDKs
PHP, Node, Python, Java, Ruby, Go
Sandbox
production-parity testing

Key benefits

What changes when payment integration solutions consolidate on one platform

Four outcomes that show up consistently once a merchant collapses many per-provider integrations into one orchestration-layer API.

  1. 01

    One payment integration in place of many

    The merchant integrates against topropay's unified API once. Underneath, the platform fans authorisations out across every connected acquirer, PSP and method — the merchant doesn't maintain per-provider SDKs, per-provider webhooks or per-provider reconciliation pipelines.

  2. 02

    Smart routing on every authorisation

    Per-transaction scoring across the connected portfolio in under 200ms; cascade through soft declines inside the same request. The same payment integration that captures the first authorisation also runs every renewal and retry on the routing engine.

  3. 03

    Three integration shapes for the same back-end

    Hosted checkout (days to live), embedded hosted fields (weeks for a custom UI), low-level SDK (full control of the surface). All three back onto the same authorisation engine, the same vault and the same reconciliation feed.

  4. 04

    One reconciliation feed across every method

    Settlements, fees, refunds and chargebacks across cards, ACH, bank rails, BNPL and (via partner gateways) crypto normalise into one ledger. Finance closes the month from one export rather than a stack of provider-specific files.

Integration patterns

Six patterns supported by the same payment integration platform

From a website checkout to ERP back-office flows, the patterns below all run through the same back-end. Pick the ones that fit your stack; turn them on independently.

  • Website

    Website payment integration

    Drop-in hosted page (redirect or iframe), embedded hosted fields, or a low-level SDK for full UI control. All three back onto the same payment integration platform; method mix and routing policy are dashboard configuration.

    • Hosted page · days to live
    • Hosted fields · PCI SAQ A-EP scope
    • Low-level SDK · full surface control
  • Online checkout

    Online payment integration for e-commerce

    An online payment integration that surfaces cards, wallets, bank rails, BNPL and crypto on the same checkout. Method availability per market is dashboard-configurable; the merchant doesn't pick a per-method snippet to embed.

    • Methods re-order per shopper's market
    • Local APMs (PIX, iDEAL, BLIK, OXXO)
    • Same authorisation engine across rails
  • ERP / back-office

    ERP payment integration and erp payment processing

    ERP payment integration pulls reconciliation, refund and dispute data into the merchant's ERP — NetSuite, SAP, Microsoft Dynamics, Odoo, Xero, QuickBooks. ERP payment system flows handle outbound payouts and supplier payments through the same API.

    • Daily reconciliation CSV / Parquet
    • Webhook stream into ERP
    • Outbound payouts on the same API
  • Forms / low-code

    Forms with payment integration

    Forms with payment integration — Typeform-style intake forms, application forms, donation forms — embed a tokenised one-line payment field via the embedded SDK or redirect to the hosted page. Same back-end as the storefront checkout.

    • Embedded one-line tokenised field
    • Hosted redirect for fastest launch
    • Webhook-driven success / failure routing
  • Bank rails

    ACH payment integration

    ACH payment integration covers one-off and recurring debits with NACHA mandate handling, R-code retry calendars and operator-side controls. Same API surface as card; rail-specific metadata fields surface in the webhook event.

    • NACHA mandate evidence
    • R-code-aware retries
    • Recurring + one-off ACH
  • Crypto

    Crypto payment integration via partner gateways

    Crypto payment integration through licensed partner crypto gateways: stablecoins, majors and L2 networks behind the same unified API as cards. Optional conversion-on-receipt keeps treasury fiat-only when the merchant prefers it.

    • USDC / USDT / BTC / ETH and others
    • Conversion-on-receipt per asset
    • Same webhook event model as card

How it works

From API key to live traffic in five concrete stages

The journey from a fresh API key to authorisations in production. Most merchants reach a live hosted-page integration in days; the rest is iteration.

  1. 01

    Pick the integration shape

    Hosted checkout for the fastest launch, embedded hosted fields for a custom UI around the form, or the low-level SDK for full surface control. All three call the same authorisation engine.

  2. 02

    Drop in the API key

    Install the server SDK in your stack (PHP, Node, Python, Ruby, Java, Go, .NET) or call the REST surface directly. Configure API keys, webhook URLs and a sandbox tenant — about an hour to first sandbox call.

  3. 03

    Switch on methods and routing

    Method availability per market and routing policy per region are dashboard configuration. The same payment integration handles cards, wallets, APMs, BNPL and crypto without per-method code changes.

  4. 04

    Authorise, cascade, settle

    Every authorisation runs through the routing engine; soft declines cascade across the connected acquirer panel in the same request. Settlement and dispute data roll up into the unified reconciliation feed.

  5. 05

    Reconcile from one feed

    Daily exports drop into ERP or warehouse with method, acquirer, region and tenant tags on every row. Finance closes the month from one source instead of per-provider files.

Main use cases

Where the best payment integration earns its keep

Six merchant shapes that share the same payment integration but stress it differently — e-commerce, SaaS, marketplaces, travel, ERP-driven enterprise, and forms-driven intake.

  • 01

    E-commerce and DTC

    Drop-in payment integration in website checkout — hosted page or embedded — with methods per market and routing across every connected acquirer.

  • 02

    SaaS and subscriptions

    Vault-token-driven renewals on top of the same integration; smart retries and scheme account updaters keep recurring revenue alive across card re-issuance.

  • 03

    Marketplaces and platforms

    Split payments, per-seller payouts and per-tenant reporting on the same integration — platform-side facilitation primitives built in.

  • 04

    Travel, ticketing and high-ticket

    Staged captures, multi-currency capture and dispute tooling per booking timeline — surfaced through the same API as one-off authorisations.

  • 05

    ERP-driven enterprise

    ERP payment processing integrations pull settlement, fee and dispute data into the ERP daily; outbound supplier payouts run through the same API.

  • 06

    Forms, donations and low-code intake

    Forms with payment integration — application forms, donor portals, event sign-ups — surface a single tokenised payment field next to the form fields.

Platform features

Capabilities behind the unified payment integration

What the platform actually ships across the API, the integration surfaces, the back-end primitives and the operator portal.

  • Unified REST API

    JSON-over-HTTPS with idempotency keys, OpenAPI specs, predictable error model and SDKs for every common back-end stack.

  • Hosted, embedded, SDK

    Three integration shapes on one back-end — pick the one that fits your team's UI control bar and PCI scope appetite.

  • Smart routing engine

    Per-transaction scoring on BIN, scheme, currency, country pair, risk and merchant policy across the connected portfolio.

  • Cascade & retry

    Soft declines cascade across acquirers inside the same authorisation; renewal traffic uses decline-reason-aware retry policy.

  • PCI DSS Level 1 vault

    Card data captures into the platform's vault; refunds, captures, recurring and updates run on vault tokens, not PANs.

  • Network tokens & SCA

    Network tokens by default; selective 3DS2 / SCA on the authorisation path — PSD2-compliant without breaking conversion.

  • Signed webhooks

    Replay-safe HMAC-signed webhooks with idempotency keys; webhook helpers per SDK; sandbox replay for testing.

  • ERP-friendly exports

    Daily reconciliation CSV and Parquet exports with method, acquirer, region and tenant tags — drops into NetSuite, SAP, Dynamics, Odoo.

  • ACH / SEPA / iDEAL / PIX

    Bank-rail integrations through the same API as card — rail-specific mandate / confirmation metadata surfaced per event.

  • Crypto via partner gateways

    Stablecoin and major-token authorisations through licensed partner gateways, exposed through the same /v1/payments endpoint.

  • Operator portal

    One dashboard for authorisations, refunds, disputes and chargebacks across every connected provider and integration shape.

  • Sandbox parity

    Per-environment sandbox that mirrors production — routing, cascade, retry, updater, refund and dispute scenarios all testable end-to-end.

Trust & compliance

Compliance posture inherited by the integration

Every integration runs through a single audited environment. Merchants inherit the platform's posture rather than carrying separate certifications per provider.

PCI DSS Level 1
Annual on-site assessment plus quarterly ASV scans; the integration inherits the platform's service-provider posture.
SCA & PSD2
Selective 3DS2 challenges on the authorisation path; PSD2-compliant in Europe without sending every shopper through a step-up.
Mandate evidence
NACHA authorisation for ACH, SEPA mandate IDs for SEPA, iDEAL bank confirmations — captured and retained per scheme rules.
Signed event delivery
Webhook events HMAC-signed; idempotency keys prevent double-actions on retry; SIEM-friendly out of the box.
Audit posture
Operator actions, refund events and cancel events logged with actor identity, reason code and timestamp.
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 integration shape.

Ready to integrate

One payment integration. Every provider, every surface.

A 30-minute integration review walks through the pattern that fits your stack — website, ERP, form-builder, ACH or crypto — the routing policy that fits, and a sandbox to test against before any commercial commitment.

Book an integration review Read the API docs

Frequently asked

Buyer questions about payment integration on topropay

Questions buyers ask before committing — integration shape, ERP fit, forms patterns, ACH mandates, crypto rails and what payment-integration-platform means in practice.

  1. 01

    What does topropay mean by payment integration?

    Payment integration on topropay is the single REST + SDK surface a merchant integrates against to authorise, capture, refund, dispute, reconcile and report on every connected acquirer, PSP and method. The merchant integrates once; the platform fans out across the connected portfolio.

  2. 02

    What are the payment integration services included?

    Payment integration services bundled with the platform include the unified API, the hosted-checkout surface, server SDKs, sandbox parity, signed webhooks, the operator portal and the reconciliation feed. For high-complexity migrations (legacy gateway swap, marketplace facilitation, custom routing) we offer a paid integration-services engagement on top.

  3. 03

    Which payment integration solutions fit a new merchant?

    Payment integration solutions for a new merchant usually start with the hosted page on a redirect — fastest to live, minimum PCI scope, days to integration. Embedded hosted fields and the low-level SDK come later if the merchant needs more UI control. The back-end shape is identical across the three.

  4. 04

    What does an online payment integration shape look like for a custom storefront?

    An online payment integration on a custom storefront is typically the embedded SDK rendering hosted fields inside the merchant's own checkout, plus a single webhook handler for state events. The merchant controls the surrounding UI; the platform controls the sensitive fields and the back-end.

  5. 05

    How does payment integration in website differ from payment integration for website?

    Payment integration in website refers to embedding payment fields directly into the merchant's checkout (hosted fields or SDK); payment integration for website is the broader term — any of hosted, embedded or hybrid. On topropay the back-end is identical; the difference is where the form is rendered.

  6. 06

    How does crypto payment integration work?

    Crypto payment integration runs through licensed partner crypto gateways exposed via the same unified API as card. The merchant calls /v1/payments with `method: usdc` (or similar); the connected gateway handles the chain side; topropay routes, reconciles and signs the webhook events the same way as card.

  7. 07

    Is erp payment integration available for common ERPs?

    Erp payment integration is supported through daily reconciliation exports (CSV, Parquet) and a signed event stream into the ERP. NetSuite, SAP, Microsoft Dynamics, Odoo, Xero and QuickBooks are common targets; the data shape is generic enough that custom ERPs can consume the same feeds.

  8. 08

    What does erp payment processing cover specifically?

    Erp payment processing through topropay covers both inbound (settlement and fee data flowing into the ERP) and outbound (supplier payouts and refunds initiated from the ERP into the platform's outbound-payment endpoints). The ERP becomes the system of record for cash; the platform handles the rail interactions.

  9. 09

    Is the platform an erp payment system in itself?

    Topropay is not an ERP — it's the payments layer that ERP integrations consume. The merchant's existing erp payment system (NetSuite, SAP, Dynamics, Odoo, Xero, etc.) stays in place; topropay handles the payment-rail interactions and feeds the ERP a normalised view of cash movements.

  10. 10

    What does website payment integration usually take?

    Website payment integration on the hosted-page path typically takes days — drop in a session-token call, render the redirect or iframe, wire one webhook handler. The embedded SDK path takes weeks for a custom UI. Either way the back-end shape is identical.

  11. 11

    Can forms with payment integration be built without a full storefront?

    Yes — forms with payment integration are a common pattern. Application forms, donor portals, event sign-ups and lead-capture forms surface a single tokenised payment field next to the form fields, calling the embedded SDK or the hosted-page redirect. No storefront required.

  12. 12

    How does ach payment integration handle mandates?

    Ach payment integration captures NACHA authorisation evidence at sign-up (timestamps, IP, descriptor, mandate text shown to the buyer); the platform retains it per scheme rules and surfaces it for audit. The recurring engine handles per-cycle ACH debits, R-code-aware retries and refund flows through the same API.

  13. 13

    Is topropay a payment integration platform or a single payment processor?

    Topropay is a payment integration platform — an orchestration layer in front of many connected processors and acquirers. A single payment processor exposes one set of methods, one rate card and one chargeback ratio; an integration platform exposes the same single API in front of the connected portfolio.

  14. 14

    What's typically considered the best payment integration shape for a multi-method merchant?

    Best payment integration shape depends on the merchant's UI bar and team. For a fast launch and minimal PCI scope, the hosted page wins. For full UI control and a custom checkout, the embedded SDK wins. For merchants who want both — cards inline and APMs hosted — a hybrid integration is common. All three share the same back-end.

  15. 15

    What does the operator-side surface look like on top of the integration?

    The operator-side surface is the topropay dashboard: authorisations, refunds, disputes, chargebacks and reconciliation across every connected provider in one place. It sits next to (not inside) the merchant's own admin; operators can also drive most actions via the API where they prefer.

Related

Related on the topropay platform