Hosted cashier · deposits & top-ups

Cashier payment for licensed operators — one hosted surface for every deposit.

A branded cashier for licensed gaming, regulated brokerages, e-money wallets and regulated subscription businesses. Card, SEPA / ACH, wallets and crypto on the same page; vault tokens for one-tap redeposits; one reconciliation feed for finance.

Book a cashier review Read the API docs
Hosted
branded cashier under the merchant's domain
Multi-rail
card, bank, wallet and crypto on one page
Vault tokens
redeposits without re-entering credentials
1 ledger
reconciliation across every rail

Key benefits

Why licensed operators pick this payment cashier shape

Four properties that show up in production the moment a cashier stops being a second checkout stack and starts sharing the same platform as the rest of the payments flow.

  1. 01

    One branded surface for every deposit

    The cashier renders as a hosted page under the merchant's domain and brand. First-time users, redeposits and top-ups all land on the same surface — no per-rail forks, no re-integrations when methods are added.

  2. 02

    Rails picked per user, not per merchant

    Card, SEPA / ACH, wallets, regional bank rails and crypto (via licensed partners) appear side by side. The routing engine ranks card acquirers per BIN behind the scenes; users see one clean surface.

  3. 03

    Redeposits via vault tokens

    Once a user's first deposit clears, the vault token drives every redeposit. Repeat top-ups don't re-collect PAN, mandate or wallet handoff — one tap, one confirmation.

  4. 04

    Compliance inherited, not rebuilt

    PCI DSS Level 1 vault, selective 3DS2, SCA orchestration, sanctions screening and per-jurisdiction rules ride on the platform. The merchant's cashier inherits the posture without carrying separate certifications.

How the cashier payment system runs

From deposit click to credited balance in five steps

What actually happens between the user tapping 'Deposit' on the merchant's product surface and the balance crediting to their account.

  1. 01

    User clicks 'Deposit' or 'Top up'

    The merchant's product surface (game lobby, brokerage dashboard, wallet app) opens the hosted cashier at the merchant's cashier domain. Session context, currency and user ID pass through as signed parameters.

  2. 02

    Cashier renders the rail list

    Available rails re-order per user market and per user history — a returning user's saved method appears first; a new user sees the market-optimal defaults. Wallets appear as one-tap options; card entry stays inline via hosted fields.

  3. 03

    Authorisation routes across acquirers

    Card authorisations route across the connected panel scored on BIN, currency, country pair and user history. Soft declines cascade inside the same authorisation — the user sees one decision, not a retry loop.

  4. 04

    Vault token issued & held

    A vault token is issued at first authorisation and stored against the user. Redeposits from the same user reference the token; refunds and chargebacks tag back to the token, not the underlying credential.

  5. 05

    Balance credited & reconciled

    Successful authorisation triggers a signed webhook back to the merchant so the balance credits in real time. Settlement files from each connected acquirer normalise into one reconciliation feed for finance.

Main use cases

Where the cashier payment gateway earns its keep

Five recurring merchant shapes that deploy the hosted cashier — always licensed, always operating in a regulated vertical or under an operator licence.

  • Gaming

    Licensed gaming operator deposits

    Licensed operators redirect players to the hosted cashier for deposits and redeposits. Cascading across acquirers lifts approval on returning-player card top-ups; vault tokens skip the redeposit form entirely.

  • Brok

    Regulated brokerage funding

    Regulated brokerages fund trading accounts through the cashier — SEPA / ACH for high-ticket, card for instant, crypto (via partners) for crypto-native clients. Reconciliation ties every credit back to the client account.

  • Wallet

    Licensed wallet-style products

    Licensed e-money wallets use the cashier for initial funding and top-ups; the vault token drives the return-user flow without the user re-entering rail details each cycle.

  • Sub

    High-ticket regulated subscription top-ups

    Regulated subscription businesses that ask users to pre-fund their balance (rather than per-charge) surface the cashier for the pre-fund step.

  • PSP

    PSPs reselling the cashier downstream

    PSPs and platforms surface the hosted cashier to their downstream merchants, branded per-merchant. The routing engine, vault and reconciliation are shared; each merchant sees only their own users and receipts.

Platform features

Capabilities behind the payment cashier

Twelve capabilities the cashier inherits from the wider platform — plus the cashier-specific primitives that make redeposits, session hand-off and balance crediting fast.

  • Hosted branded cashier

    Per-merchant subdomain, colour, logo and copy; PCI SAQ A scope for the merchant.

  • Rail list per user market

    Card, SEPA / ACH, wallets, regional bank rails and crypto (via partners), re-ordered per user country and history.

  • Vault tokens for redeposits

    First-deposit tokenisation; returning users skip form re-entry entirely.

  • Smart routing across acquirers

    Per-BIN, per-currency, per-country routing across the connected panel; cascading on soft decline.

  • Selective 3DS2 / SCA

    PSD2-compliant challenges per authorisation; frictionless flows pass through where allowed.

  • Refund controls, operator-side

    Refunds tied to the vault token; operator-side justification, actor identity and timestamp logged for every event.

  • Signed webhooks

    Auth, capture, settlement, refund and dispute events fire to the merchant with replay-safe signed IDs.

  • Chargeback & dispute queue

    One queue across every connected acquirer; evidence-pack templates per vertical.

  • Multi-currency

    Cashier displays in the user's currency; settlement runs in the merchant's configured currencies.

  • Session hand-off

    Signed query-string parameters pass user ID, currency and return URL from the product surface.

  • PCI DSS Level 1 vault

    Card data captures into the platform vault before any acquirer sees it; PAN never lands in merchant systems.

  • One reconciliation feed

    Settlements, fees, refunds and chargebacks from every connected acquirer normalise into one ledger.

Industry relevance

Cashier fit for licensed EU, UK, APAC and LATAM operators

topropay's cashier posture targets licensed operators across Europe, the UK, APAC and LATAM. Deployment always follows the operator's licensing scope in each jurisdiction — the hosted cashier is not offered outside the operator's legal perimeter, regardless of user location.

  • Licensed gaming operators (where licensed)
  • Regulated brokerages
  • Licensed e-money wallets
  • Regulated subscription platforms (pre-funded)
  • PSPs reselling to licensed merchants
  • Unlicensed gambling · out of scope
  • Grey/black-market operators · out of scope
  • Adult-content operators · out of scope

Trust & compliance

Compliance posture inherited by every cashier surface

One audited environment underpins every cashier, plus scheme-programme posture per connected acquirer surfaced in the operator's dashboard.

PCI DSS Level 1
Annual on-site assessment plus quarterly ASV scans; sub-merchants inherit the posture on every cashier surface.
SCA & PSD2
Selective 3DS2 on the authorisation path keeps approval high in Europe without skipping the SCA bar.
Sanctions & AML alignment
Sanctions screening at onboarding; AML monitoring tuned per merchant vertical, volume and user-country mix.
Scheme programme posture
Visa VDMP / VAMP / VFMP and Mastercard ECP / EFMP positions per connected acquirer surfaced in the dashboard.
Audit-grade event log
Every cashier action — session open, method selected, authorisation attempted, refund raised — logged with actor, timestamp and IP.
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 cashier configuration.

Ready to unify the deposit surface

Deploy a hosted cashier for your licensed operator.

A 30-minute cashier review covers the rails relevant to your user markets, the routing weights tuned to your BIN mix, the session hand-off contract to your product surface and a sandbox to test against before any commercial commitment.

Book a cashier review Read the API docs

Frequently asked

Buyer questions about the cashier payment on topropay

Definitions, session hand-off, redeposit UX, dispute mechanics and the practicalities of running a hosted cashier under a licensed operator's brand.

  1. 01

    What does topropay mean by a cashier payment surface?

    A cashier payment surface on topropay is a hosted, per-merchant page that handles deposits, top-ups and redeposits. It renders under the merchant's cashier subdomain, in the merchant's brand, and covers every rail the merchant has enabled — card, bank rail, wallet and crypto — through one integration on the back-end.

  2. 02

    How does the payment cashier differ from a standard checkout?

    A standard checkout collects payment for a specific cart or invoice — one authorisation per session, tied to an order. A payment cashier is longer-lived — the same user returns repeatedly to top up a balance. Vault tokens, redeposit flows and account-history rendering are cashier-specific features that a one-off checkout doesn't need.

  3. 03

    Is the cashier payment gateway a separate product from topropay's main gateway?

    No. The cashier payment gateway on topropay is the same unified gateway with a cashier-shaped surface on top. The routing engine, vault, reconciliation feed and dispute queue are shared with the wider platform — the cashier is a rendering layer plus a set of cashier-specific webhooks and session-hand-off primitives.

  4. 04

    What does the cashier payment system look like end-to-end?

    The cashier payment system end-to-end runs: user clicks 'Deposit' on the merchant's product surface → cashier opens with signed session context → user picks a rail from the market-optimised list → authorisation routes across the connected acquirer panel → vault token issues → signed webhook fires to credit the balance → reconciliation row lands in the unified ledger.

  5. 05

    Can the payment cashier system be branded per merchant?

    Yes. The payment cashier system supports per-merchant branding — subdomain (e.g. cashier.<merchant>.com), colour tokens, logo, header copy and legal footer. Multiple merchants under one platform (PSP resellers) each get their own branded cashier without operating independent stacks.

  6. 06

    How does the cashier handle first-time vs returning users?

    First-time users see the market-optimal default rail list (typically card at the top for most markets, plus a regional bank rail and wallet). Returning users see their saved method (via vault token) at the top with a one-tap redeposit option; the rest of the rail list is available below for switching.

  7. 07

    What redeposit UX does the cashier support?

    For redeposits, the cashier displays the user's saved method with a masked identifier (e.g. 'Visa ending 4771') plus a one-tap 'Redeposit' button. Under the hood the vault token drives the authorisation; the user doesn't re-enter PAN, mandate or wallet handoff unless they explicitly choose a different rail.

  8. 08

    How does the cashier hand off from the merchant's product surface?

    The merchant's product surface opens the cashier via a signed URL carrying user ID, currency, amount hint (if any), and the return URL. Cashier events (success, cancel, method chosen, amount typed) fire back to the merchant via signed webhooks, and the user is redirected back to the merchant's return URL when the session closes.

  9. 09

    Are the merchants who typically deploy a cashier licensed?

    Yes — the merchants deploying a cashier on topropay are licensed operators in their target jurisdictions: licensed gaming, regulated brokerages, licensed e-money wallets and regulated subscription businesses. topropay does not serve unlicensed operators regardless of the acceptance surface shape.

  10. 10

    Can the cashier be embedded rather than fully redirected?

    Yes. Where the merchant wants an embedded flow, hosted fields render the card entry (and equivalents for other rails) as iframes inside the merchant's own product surface. PCI scope stays at SAQ A-EP; the cashier back-end is the same. Full-redirect stays available for merchants who prefer SAQ A.

  11. 11

    How are chargebacks and refunds handled on cashier receipts?

    Chargebacks and refunds tie back to the vault token issued at the original authorisation. The unified dispute queue surfaces the case with the linked user, session, method and settlement rows pre-loaded; refund actions require operator-side justification and log actor identity, reason and timestamp.

  12. 12

    What kinds of authorisation velocity does the cashier support?

    The cashier supports per-user, per-session and per-day velocity rules — hard caps on amount and count, plus soft rules that step-up authentication or route via a lower-limit acquirer. Merchants tune the rules per vertical and per player / user segment.

  13. 13

    How quickly does a merchant go from contract to first cashier deposit?

    Most merchants go from contract to first cashier deposit in 2–6 weeks depending on KYB depth, scheme-programme registrations required by the target verticals, and the merchant's own product-side integration timeline. Sandbox coverage runs from day one.

  14. 14

    Does the cashier support crypto deposits?

    Crypto deposits are delivered through licensed partner crypto gateways surfaced inside the same cashier UI. Optional conversion-on-receipt keeps treasury fiat-only; on-chain deposit confirmations trigger the same signed-webhook flow as card and bank-rail deposits.

  15. 15

    What about card-present deposits at a physical cashier / cage?

    Card-present deposits at a physical cashier or cage are handled through the partner POS / SoftPOS estate on the omnichannel side of topropay. Vault tokens are shared across the online cashier and card-present flows, so a user who deposits at the cage can be refunded through the online cashier and vice versa.

Related

Related on the topropay platform