Continuously expanding

New payment methods — added on the platform side, live as a dashboard toggle.

The connected method catalogue grows every month. New wallets, new bank rails, new BNPL products, new crypto networks, new acquirer connections — added by the platform, surfaced as toggles in the merchant's dashboard, no re-integration and no checkout re-deploy.

300+
methods available today
Monthly
cadence of new-method additions
0
merchant-side re-integration required

Key benefits

Why continuous new payment systems beat one-off provider migrations

Four properties that flip the moment new-method availability moves off the merchant's engineering backlog and onto the platform's connectivity roadmap.

New methods land as a dashboard toggle

When a new payment method is added to the platform, it becomes an option in the merchant's dashboard. Enabling it doesn't require re-deploying the checkout code — the same authorise endpoint carries it.

New gateways connect on the platform side

A new payment gateway added to the connected panel becomes another routable lane in the routing engine. The merchant's integration doesn't change; the routing policy picks the new lane per its scoring.

New processors ride the same API

A new payment processor connected under a new acquirer relationship exposes the same REST contract as every existing processor. Merchants get the new provider by weighting it up, not by writing new code.

New rails on the same reconciliation feed

Whether it's a new bank rail, wallet, BNPL or crypto network, settlement rows normalise into the same ledger — tagged with method, provider and currency for finance.

How new payment gateway additions land

From a new gateway connection to a live dashboard toggle in four steps

What actually happens between the connectivity team wiring a new provider into the routing engine and the merchant enabling it in their checkout.

  1. 01

    Method vetted and connected

    topropay's connectivity team vets the new provider or method, negotiates commercials, and connects it to the routing engine on the platform side. No merchant action required.

  2. 02

    Surfaces in the dashboard

    The new method appears in every eligible merchant's dashboard as an available option, gated by market, vertical and licence where applicable.

  3. 03

    Merchant toggles it on

    A single toggle enables the new method for the merchant's checkout, hosted pay link or invoice surface. The rendering is dynamic; no re-deploy.

  4. 04

    Reconciliation from day one

    The new method's settlements flow into the same reconciliation feed with the appropriate method, provider and currency tags. Finance sees it in the next daily export.

Main use cases

Where a rolling new payment processor stream earns its keep

Five merchant shapes that benefit directly from continuous method additions rather than provider-migration projects.

  • DTC

    DTC brands adding regional methods on expansion

    New PIX-Recorrência for the Brazil launch, new iDEAL 2.0 for the Netherlands launch — all as dashboard toggles rather than integration projects.

  • SaaS

    SaaS billing adopting a new BNPL

    A new payment solutions like Klarna Pay Now added for annual invoices — the recurring engine picks it up automatically.

  • Plat

    Marketplaces enabling new payout rails per seller

    New Visa Direct push-to-card payouts activated for one seller cohort while the rest continue on SEPA Credit Transfers.

  • Enter

    Enterprise merchants trialling a new payment processor

    New payment processor added to the routing panel with a low weight for parallel A/B; weight ramps up as approval data comes in.

  • Crypto

    Crypto-native merchants opting into new stablecoin networks

    New L2 stablecoin network exposed via a new payment gateway partner; merchant opts in with a dashboard toggle.

Platform features

Capabilities behind the new payment solutions pipeline

Twelve capabilities the platform ships once and reuses across every new method — the primitives that make additions land as toggles rather than projects.

  • Continuous method addition

    New card BINs, wallets, bank rails, BNPL and crypto networks added on a rolling basis; no per-addition integration project.

  • Provider-agnostic API

    One REST contract regardless of which connected provider clears the auth; new providers slot in behind it.

  • Routing weight editor

    Dashboard editor for weighting new lanes into the routing engine — start at low weight for A/B, ramp on data.

  • Sandbox parity

    Sandbox exposes every new method the moment it's connected, so integration tests catch surface changes before production toggles them.

  • Per-market gating

    Every new method is gated by market, currency and vertical to keep irrelevant options off the checkout.

  • Scheme programme awareness

    New card connections respect Visa VDMP/VAMP/VFMP and Mastercard ECP/EFMP programme posture from day one.

  • PCI DSS Level 1 vault

    Card-data new methods inherit the platform vault; PAN never lands on the merchant device regardless of which new provider clears the auth.

  • Network tokens by default

    New card lanes provision VTS/MDES network tokens automatically; recurring survives re-issuance from the first authorisation.

  • Mandate handling per rail

    New bank rails (SEPA SDD, Bacs, ACH) capture and retain mandate IDs per scheme rules from the moment they're enabled.

  • Unified dispute queue

    Disputes on a new method surface in the same queue as every other method; evidence-pack templates cover the new scheme's requirements.

  • Auto-close on settlement

    New payment methods that clear settlement files flow into the same auto-close and reconciliation pipeline as every existing method.

  • Deprecation-safe migration

    When a legacy method is retired, its vault tokens migrate to the successor method through platform-side mapping; the merchant doesn't re-request customer details.

Industry relevance

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

topropay's continuous new-method pipeline targets licensed merchants and licensed PSPs operating across EU, UK, APAC and LATAM markets. Every addition passes the same vetting bar — geographic licensing, scheme posture, dispute programme readiness — regardless of the size of the connectivity effort behind it.

  • DTC · cross-border retail
  • SaaS & subscriptions
  • Marketplaces & platforms
  • Travel & ticketing
  • Professional services & B2B
  • Licensed gaming operators (where licensed)
  • Adult content · out of scope
  • Unlicensed gambling · out of scope

Trust & compliance

Compliance posture that extends to every new method the day it's connected

One audited environment for the orchestration layer; every new method inherits the posture from the moment it's connected. Merchants don't recertify per addition.

PCI DSS Level 1
New card-data methods inherit the platform's PCI L1 posture from the moment they're connected; no additional certification for the merchant.
SCA & PSD2
Selective EMV 3DS2 on any new card lane in Europe from day one; frictionless flows pass through, step-up where issuer or amount require it.
Bank-rail mandate posture
NACHA authorisations for new ACH lanes, SEPA mandate IDs for new SEPA Direct Debit lanes, Bacs DDIC for new UK bank-rail lanes.
Crypto via licensed partners
New crypto rails delivered through licensed partner crypto gateways with VASP/MiCA-relevant authorisations; AML/KYC inherited.
Sanctions & AML alignment
Sanctions screening at onboarding continues; AML monitoring adjusts to the new method's risk profile without merchant configuration.
Licensed verticals only
New methods on topropay serve licensed merchants. Grey and black-market verticals remain out of scope regardless of which new method is connected.

Ready to stop chasing new integrations

Get every new payment method as a dashboard toggle.

A 30-minute coverage review covers the methods relevant to your current markets, the ones coming in the next quarter, and the routing policy that decides how new lanes take initial share — followed by a sandbox to test against.

Frequently asked

Buyer questions about new payment methods on topropay

Cadence of additions, sandbox parity, routing behaviour, deprecation-safe migration and the practicalities of running on a continuously expanding method catalogue.

  1. 01

    What does 'new payment methods' mean on topropay?

    New payment methods on topropay means the ongoing stream of additions to the connected method catalogue — new card schemes, new BINs, new wallets, new BNPL products, new bank rails, new crypto networks and new regional rails. The platform side does the integration work; merchants get the addition as a dashboard toggle.

  2. 02

    How often do new payment systems appear on the platform?

    New payment systems appear on the platform roughly monthly. Some are minor (a new BIN range, a new wallet region), others are major (a whole new rail like PIX-Recorrência or a new BNPL provider). All follow the same connectivity, vetting and reconciliation pipeline.

  3. 03

    Does adding a new payment gateway require re-integration on the merchant side?

    No. A new payment gateway added to the connected panel becomes another routable lane inside the same unified API. The merchant integrates once — the routing policy picks the new lane per its scoring. The merchant can adjust routing weights via the dashboard without code changes.

  4. 04

    How is a new payment processor evaluated before it's added to the panel?

    A new payment processor is evaluated on geographic coverage, scheme licensing, dispute programme posture, operational stability and integration cleanliness. Once connected, it starts at a low routing weight so approval / cost / dispute data can be measured before it takes production volume.

  5. 05

    What kind of new payment solutions are typically added?

    New payment solutions typically added include: new wallet integrations (Click to Pay v2, regional wallets), new BNPL products (Apple Pay Later, Klarna, Afterpay, Atome), new bank rails (PIX-Recorrência, iDEAL 2.0, Bacs updates), new crypto networks (L2 stablecoins, PYUSD), new push-to-card payout products (Visa Direct, Mastercard Send) and new acquirer connections for existing schemes.

  6. 06

    Can merchants request specific new methods?

    Yes. Merchants routinely request specific methods relevant to their markets or verticals — a specific wallet in a specific country, a specific BNPL for a specific ticket range. The connectivity team prioritises requests where multiple merchants have overlapping demand and where the vetting bar can be met.

  7. 07

    How does routing behave when a new payment method is enabled?

    When a new payment method is enabled, the routing engine surfaces it as an available lane for eligible authorisations (matching BIN, currency, country, vertical). Initial weight is set conservatively; the merchant can raise it based on actual approval and cost data from the first cohort of transactions.

  8. 08

    Are new methods available in sandbox before production?

    Yes. Sandbox parity is a hard requirement — every new method is exposed in sandbox from the moment it's connected. Integration tests run against the new method's surface before any merchant toggles it on in production.

  9. 09

    What happens to existing customer data when a new method replaces an old one?

    When a new payment method is functionally the successor to a legacy one (e.g. VTS network tokens replacing raw PANs, or PIX-Recorrência replacing a partner-specific recurring), vault tokens migrate through platform-side mapping. The merchant doesn't re-request card details from customers; the vault token continues to reference the new method underneath.

  10. 10

    Do compliance and PCI posture apply to new methods automatically?

    Yes. PCI DSS Level 1 vault, selective 3DS2, sanctions screening and AML monitoring all extend to any new card-data method the moment it's connected. New bank rails inherit the platform's NACHA / SEPA / Bacs mandate handling. New crypto rails inherit the VASP / MiCA-relevant partner authorisations.

  11. 11

    What if a new method has poor approval rates?

    The routing engine's scoring picks this up automatically. A new method with poor approval rates on a given merchant's traffic mix gets down-weighted; if the engine's confidence is high, it can effectively deprecate the lane until data changes. The merchant can also override routing weights manually in the dashboard.

  12. 12

    How does reconciliation handle a new payment method's settlements?

    New settlement files from a new provider flow into the same normalisation pipeline as every existing provider. Each row is tagged with the method, provider, currency, scheme (where applicable) and merchant. Finance reads the same daily CSV or API export they always read.

  13. 13

    Is there a public roadmap of upcoming new methods?

    Detailed upcoming-method timelines are shared under NDA during onboarding and per-quarter reviews. Publishing a public roadmap of connectivity work isn't useful — the connectivity pipeline shifts as partner readiness and merchant demand change; what matters to the merchant is that additions arrive as dashboard toggles rather than integration projects.

  14. 14

    Can PSPs offer downstream merchants the new-method stream too?

    Yes. PSPs and resellers inherit the same new-method stream. Their downstream merchants see the same dashboard-toggle model, gated per merchant's market, vertical and routing policy. The PSP can also curate which new methods are visible to which merchant cohorts.

  15. 15

    What isn't in scope for the new-methods pipeline?

    Methods designed primarily for grey or black-market verticals aren't added, regardless of demand. Similarly, methods that would require topropay to hold a licence the platform doesn't hold (e.g. direct RBI Payment Aggregator status in India) are delivered through licensed partner gateways rather than as a direct platform-side connection.