Payment page
topropay powers the payment page on the merchant's website — hosted as a drop-in, embedded as inline hosted fields, or a hybrid of the two. Behind the form: routing across every connected acquirer, the PCI DSS Level 1 vault, and a single reconciliation feed across every method the merchant accepts.
Key benefits
Five outcomes that show up most consistently once the payment page is wired through the platform — covering speed, reach, approvals, security and operations.
The hosted payment page drops into the merchant's checkout via a redirect, an iframe or a tokenised script tag. Cards, wallets, bank rails and BNPL surface at launch; the rest is dashboard configuration.
The same payment page surfaces cards, Apple Pay / Google Pay, local APMs per market (PIX, BLIK, iDEAL, OXXO, PayID), BNPL and (via partner gateways) stablecoins. The visible method list re-orders per shopper's market.
The buyer sees one clean form; behind it, every authorisation runs through the routing engine. Soft declines cascade to the next ranked acquirer inside the same request — the buyer never sees a per-provider retry.
Sensitive fields capture inside the platform's PCI DSS Level 1 vault before the merchant's origin ever touches them. The merchant inherits the service-provider posture rather than carrying it themselves.
Settlements, fees, refunds and chargebacks across every connected acquirer normalise into one ledger keyed off vault tokens. Finance closes the month from one export rather than a stack of acquirer-specific files.
How it works
Most merchants are live in days on the hosted page; the embedded and SDK paths take weeks. The work shape is the same — integration first, configuration second, iteration afterwards.
Hosted page (redirect or iframe), embedded with hosted fields (PCI Level A scope), or a low-level SDK for full control of the surface. All three back onto the same authorisation engine.
Switch on methods per market, set routing policies (approval-, cost- or composite-weighted) and risk thresholds — all from the dashboard, no release required.
Hosted page: a redirect or iframe with a signed session token. Embedded: hosted fields rendered inline. Either way the merchant's origin never touches PAN data.
Authorisations run through the routing engine; soft declines cascade; captures, refunds and chargebacks operate on vault tokens; settlement and dispute data roll up into the unified reconciliation feed.
Integration shapes
Three valid shapes for surfacing the payment page on the merchant's website. The difference shows up in PCI scope and UI control; the back-end is the same orchestration layer.
The buyer leaves the merchant's site (or sees an iframe) for the platform-hosted checkout. PCI scope sits with topropay; the merchant integration is a signed session token plus a webhook handler.
Card-number, expiry and CVV fields are rendered as hosted iframes inside the merchant's own checkout. The rest of the page is fully under the merchant's control; sensitive data still captures into the vault.
Cards via embedded hosted fields for full-control surface; BNPL, wallets and local APMs via the hosted page where the provider's UI is best left intact. Same back-end, two front-ends.
Methods on the page
A sample of the methods the payment page can surface, grouped by category. Per-market availability and ordering are dashboard-configurable; the page re-orders the visible list to the shopper's market on render.
Main use cases
Six merchant shapes that share the same payment-page primitives but stress them differently. The product is the same; the integration shape and method mix vary.
An ecommerce website payment gateway integration with a drop-in payment page handles the long tail of methods per market without per-provider work on the merchant side. The result: a checkout that converts in every market the brand sells in.
The hosted payment page handles initial sign-up; vault tokens drive renewals, retries and account-updater flows behind the scenes. Cancel and dunning surfaces remain under merchant control.
A single payment page per seller (or per cart) with split-payment routing in the back-end; per-tenant reporting in the merchant dashboard.
High-ticket bookings benefit from a hosted page with staged-capture and multi-currency support out of the box; refunds and partial captures run via the same authorisation engine.
Reseller-side white-labelling lets a PSP brand the hosted page per merchant; the back-end orchestration is shared.
Where the brand needs full control of the checkout surface — pricing UI, animations, custom validation — the embedded SDK gives the form primitives without dragging PAN data into the merchant origin.
Platform features
What the platform actually ships for the payment page surface — and the back-end it sits on.
Drop-in checkout via redirect or iframe; signed session tokens; brandable surface; localised method ordering per market.
Card number, expiry and CVV inputs rendered as iframes inside the merchant's own page; the rest of the UI is the merchant's.
Full-control SDK for custom checkout surfaces; same vault, same authorisation engine.
Per-transaction scoring on BIN, scheme, currency, country pair and risk — ranked routes per authorisation.
Soft declines cascade to the next ranked acquirer in the same request; nothing leaks back to the buyer.
Sensitive data captures into the vault before the merchant origin ever sees it; refunds, retries and recurring run on vault tokens.
Selective challenges per transaction — PSD2-compliant in Europe without breaking conversion.
Signed, normalised events into your SIEM, warehouse or in-house tooling.
Settlements, fees, refunds and chargebacks across every connected acquirer normalised into one ledger.
Per-environment sandbox that mirrors production, including routing and cascade scenarios.
Trust & compliance
The compliance shape that every payment page on the platform inherits — regardless of whether it's hosted, embedded or SDK-rendered.
Ready to ship
A 30-minute checkout review walks through hosted vs embedded vs hybrid, the methods relevant for your markets, and a sandbox to test against before any commercial commitment.
Frequently asked
What buyers ask before they commit — covering integration shape, cost, methods, customisation, vertical fit and the verticals the platform doesn't serve.
It looks like a clean payment form — the merchant picks the shape (hosted, embedded, hybrid) and the platform handles the back-end. Cards, wallets and local methods are surfaced in the order most likely to convert for that shopper's market; behind the scenes, every authorisation runs through the routing engine and lands in the unified ledger.
A website payment gateway integration on topropay collapses many providers into one API. Instead of integrating against acquirer A, then acquirer B, then BNPL provider C, the merchant integrates against the unified payments API once. The platform routes between providers per transaction; the merchant doesn't see the seams.
A typical website with payment gateway setup on topropay is one of: (a) hosted page via a redirect or iframe — fastest to launch, days; (b) embedded hosted fields — weeks for a custom UI around them; (c) low-level SDK — weeks for full surface control. All three share the same back-end and reconciliation.
Website payment solutions vary by merchant: DTC brands usually pick the hosted page for speed; SaaS / subscription merchants pick embedded hosted fields for renewal-flow UI control; marketplaces tend to pick the SDK for split-payment routing; high-ticket travel often picks hybrid (cards embedded, BNPL hosted).
A website with payment processing — as opposed to a website with payment gateway — implies the rest of the back-end is in scope: authorisation, capture, refund, dispute, reconciliation. topropay handles all of that under one integration, so the difference is mostly framing rather than scope.
An ecommerce website payment gateway integration on the platform includes the hosted checkout (or embedded fields), the unified payments API, the routing engine, the vault, signed webhooks and the operator portal. The merchant doesn't bolt on a separate fraud, reconciliation or analytics tool — they're included.
Website payment methods on the platform include cards, wallets (Apple Pay, Google Pay, Click to Pay), bank rails (SEPA, Bacs, Open Banking, iDEAL, BLIK, PIX, OXXO, PayID), BNPL (Klarna, Afterpay, Affirm) and crypto via partner gateways. The visible list per market is dashboard-configurable.
Adult website payment processing is out of scope for topropay. The platform supports licensed and regulated merchants in mainstream and high-risk verticals (subscriptions, travel, ticketing, licensed gaming, nutraceuticals and similar), but it does not cater for adult, unlicensed gambling or other grey- / black-market verticals — regardless of the integration shape or the merchant's preferred provider.
The hosted website payment page is customisable through dashboard CSS overrides (colours, typography, button shapes, layout density) plus a brand-mark. For pixel-perfect control the merchant uses the embedded hosted-fields or low-level SDK paths.
Yes — the secure payment page posture (PCI DSS Level 1 vault, selective 3DS2 / SCA, signed webhooks, vault-token-only refund flows) is identical across hosted, embedded and SDK paths. The integration shape changes who renders the UI, not where sensitive data lives.
To create website with payment gateway support quickly, drop the hosted payment page into the checkout via a redirect or iframe; configure methods and routing from the dashboard; wire one webhook handler for authorisation, capture, refund and chargeback events. Most teams reach a live integration in days through this path.
To create a website with payment gateway without deep engineering, the hosted-page redirect path is usually enough — most ecommerce platforms (Shopify-like, WooCommerce-like, custom stacks) can wire it via a session-token call and a single webhook. The merchant doesn't need a payments-engineering team to maintain it.
Cost of website with payment gateway integration on topropay is a per-authorisation fee on top of the underlying provider economics — there's no platform retainer, no per-environment fee, no minimum monthly. Interchange and scheme fees pass through where the underlying provider supports it; the platform's fee is a separate line on the invoice.
Ecommerce website payment methods that convert best are market-specific. Cards convert in most markets; iDEAL in the Netherlands, BLIK in Poland, PIX in Brazil, OXXO in Mexico, PayID in Australia and Open Banking in the UK regularly outperform cards on local traffic. The routing engine ranks them on the merchant's own outcomes.
High-ticket transactions benefit from staged-capture and multi-currency support — both available on the hosted page and the embedded SDK paths. 3DS / SCA is applied selectively, and the routing engine weighs dispute risk into the route choice on those transactions.
Related