Every payment method online
topropay connects you to cards, the ACH payment method, SEPA, Skrill, Paysafecard, MB WAY and hundreds of other rails through one unified API. Smart routing picks the best provider per transaction, and cascading retries recover the sales a single payment method declined event would otherwise lose.
Shoppers no longer want to pay one way. A buyer in Lisbon expects MB WAY; a US subscriber expects the ACH payment method; a German shopper expects SEPA Direct Debit at renewal; a traveller checking out from a hotel expects their wallet of choice. Each missing method quietly costs conversion in that market.
topropay puts every connected payment method behind one integration, so the question shifts from "which provider should we build to next?" to "which method should we switch on next?" When an authorisation fails on one rail, the engine cascades to another inside the same request — so 'your payment method was declined' becomes a recovered sale instead of a checkout dead-end.
Key benefits
Three outcomes show up first when methods stop being one-integration-per-provider and start being one configuration choice each.
Cards, digital wallets, account-to-account rails, voucher schemes and country-specific methods all sit behind the same unified API. Adding the next method is a configuration change in the dashboard, not a fresh engineering build per provider.
Soft declines trigger automatic cascading to the next ranked route in the same authorisation request — your checkout sees a single clean result. Decline reasons, retry policy and account-updater logic are tunable per method, so renewal recovery is a configuration choice rather than a per-provider script.
Shoppers convert better when they see the method they already use. Surface SEPA in the eurozone, ACH in the US, MB WAY in Portugal, Blik in Poland, iDEAL in the Netherlands, e-wallets in APAC — each one rendered to the local market without rebuilding the checkout.
How it works
Three steps describe the path of any transaction, regardless of the method the shopper chose at checkout.
The shopper picks a method at checkout. Our hosted fields, drop-in widget or server-to-server flow capture the payload into a PCI DSS vault — your origin never holds raw card data or sensitive credentials.
The routing engine scores the request and picks the rail most likely to approve at the lowest cost. If it returns a soft decline, the cascade fires inside the same call — the shopper sees one final result.
Funds settle on each provider's cycle and a unified ledger normalises fees, refunds, chargebacks and forex — so finance closes against one consistent dataset regardless of how many methods you offer.
Where it fits
One pattern dominates the savings — the others stack on top.
Recurring billing is where the cost of declines compounds fastest. The platform keeps each card on file as a vault token, runs intelligent retries on soft declines, calls the account updater on stored cards, and silently cascades across acquirers — so a single payment method declined event does not become a churn event.
Sell into new countries with the local payment method online that shoppers expect, behind the same checkout.
Split payouts and seller settlements across the same set of methods, with reconciliation that keeps every party's ledger straight.
Staged captures, partial refunds and multi-currency capture, with the redundancy high-value baskets demand.
Features & methods
A grounded list rather than a marketing wall — what the platform actually surfaces inside the unified checkout, with the rail family, the region it lives in and the typical use.
| Method | Type | Regions | Note |
|---|---|---|---|
| Cards (Visa, Mastercard, Amex) | Card | Global | Primary rail with 3DS2 / SCA where required. |
| ACH payment method | Bank transfer | United States | Lower cost per transaction; ideal for high-value or recurring flows. |
| SEPA Credit Transfer & Direct Debit | Bank transfer | Eurozone | Native euro rails for one-off and recurring debits. |
| Apple Pay, Google Pay | Wallet | Global | Frictionless tap-to-pay at checkout with tokenised cards. |
| Skrill | E-wallet | Europe & global | Payment method Skrill for shoppers who prefer to pay from a wallet balance. |
| Paysafecard payment | Prepaid voucher | Europe & LATAM | Cash-funded vouchers; useful where shoppers prefer not to share card data. |
| MB WAY payment | Mobile wallet | Portugal | MB WAY payment is the dominant local mobile flow in Portugal. |
| Open banking & A2A | Bank transfer | Europe, UK, LATAM | Instant account-to-account confirmations with PSD2 alignment. |
| Local schemes (iDEAL, Bancontact, Blik, …) | Local | Per market | Domestic rails surfaced alongside cards in the same checkout. |
The catalog evolves — the dashboard shows the live list of what is actually switched on for your account, with the routing rules each method participates in. Adding a new method, including regional rails like MB WAY payment in Portugal, takes a switch in the dashboard rather than a fresh engineering build.
Decline handling
The biggest revenue lift from a unified methods layer is not on first-time approvals — it is on what happens after the first failure. The platform classifies declines and acts on them, instead of forwarding a generic 'this payment method has been declined' to the buyer.
When a soft decline comes back from the issuer (insufficient funds, do-not-honour, network timeout), the engine cascades to the next ranked acquirer inside the same call. The shopper sees one outcome instead of a 'this payment method has been declined' screen.
A genuine hard decline (closed account, lost or stolen card) is final and surfaces a clean message at checkout. The portal records the reason against the transaction so the team can act on it without guessing.
A 'transaction declined invalid payment method' error usually means the customer's card scheme or method is not supported on the selected rail. The router automatically tries another configured rail and, where appropriate, prompts the shopper to switch method without leaving the checkout.
Industry relevance
Different businesses lean on different rails. The same orchestration layer serves all of them; only the policy changes.
Trust & compliance
Every connected rail inherits the same compliance posture, so adding a method does not re-open your audit.
For the deeper compliance story see the payment card industry PCI compliance page; for the routing engine behind every method, see smart routing and cascading.
Common questions
It is the generic message a checkout shows when the issuing bank or the network refuses to authorise a charge on the selected method. The underlying reason can be anything from insufficient funds to a soft network error to a hard fraud-prevention block. topropay records the granular decline reason behind that generic message, then either cascades the request to another acquirer (soft declines) or surfaces a helpful next step for the shopper (hard declines).
The most common pattern is a soft decline that an individual gateway cannot retry, so the merchant sees a final 'this payment method has been declined' message even though the same transaction would succeed on another route. Sitting an orchestration layer in front of multiple acquirers turns that final message into a recovered authorisation, because the cascade fires before the shopper is shown the failure.
Yes. ACH as a payment method is available for US merchants, alongside cards, wallets and account-to-account rails. The ACH payment method is particularly useful for recurring billing and high-value transactions where the per-transaction cost of card processing is a meaningful share of the unit economics. Operationally, payment method ACH behaves like any other rail behind our unified API — you switch it on in the dashboard, set the routing policy, and reconcile through the same ledger.
Yes. Payment method Skrill is a connected e-wallet that sits next to cards, wallets and bank transfers in the unified checkout. Shoppers who already hold a Skrill balance can pay without re-entering card details, and the transaction shows up in the same payment view as any other rail.
Yes. Paysafecard payment is supported as a prepaid voucher method, useful in markets where a meaningful share of buyers prefer cash-funded vouchers to entering card data. It connects through the same API and reconciles into the same ledger.
Payment method SEPA — both Credit Transfer and Direct Debit — sits in front of cards in many euro-area markets because it is cheaper and more familiar than a card payment for recurring debits. The router treats SEPA like any other rail: it can lead for users who prefer to pay from their bank, sit in the cascade as a fallback, or be the default for renewals while cards are reserved for one-off purchases.
Yes. The mb way payment flow is supported in Portugal as a local mobile wallet rail; shoppers approve the charge inside the MB WAY app and the platform records the result alongside every other rail. There is no separate checkout to maintain.
That error means the customer's card scheme or method is not supported by the rail the request was sent to. The router automatically tries another configured rail where one is available, and the portal records the original error so the operations team can decide whether to add a method to that market.
Every e payment method connected to your account renders inside the unified checkout, with its own logo and a localised label per market. The shopper picks the way they want to pay; the routing engine decides which provider clears it. The merchant only maintains one set of method assets, not one per gateway.
It is built for scale. Per-transaction routing, cascading retries, redundant acquiring and a normalised ledger across every method are designed for merchants and PSPs processing serious volume. If 'what is the right way, payment-wise, for our next region?' is a question your team asks every quarter, the answer is the configuration choice the platform exposes — not a fresh integration project.
No. Methods render on the client; routing decisions are made in milliseconds inside the same payment request. Cascading retries on a soft decline happen behind the scenes, so the shopper experiences a single fast result rather than a failed attempt followed by a retry.
Book a walk-through. We map the methods you offer today, score where authorisations leak, and show how a single integration turns 'your payment method was declined' from a final message into a recovered transaction.
Related