Payment crypto

Payment crypto — accept stablecoin and majors through one API.

topropay surfaces crypto rails inside the same unified API as cards, wallets and bank rails. Accept payment in crypto on the website or in store, convert on receipt or hold the asset, and reconcile every receipt in one ledger.

Book a crypto review Read the API docs
wallet · pay merchant

To

topropay · M-9421

Amount

189.00 USDC

≈ €189.00 · locked for 12:30

  • Base
  • Arbitrum
  • Polygon

Routed through topropay · convert on receipt: on

Wallet → topropay → merchant ledger row.
USDC · USDT · BTC · ETH
supported via partner gateways
<1m
typical confirmation on L2s
Convert
on receipt — optional, per asset
1 ledger
across crypto, card and ACH

Key benefits

Why payment with crypto on one API wins on every axis

Four outcomes that show up consistently once crypto rails sit alongside card and bank rails on the same orchestration layer rather than in a separate console.

  1. 01

    Accept payment in crypto on the same checkout as cards

    Crypto rails — stablecoins, majors and L2 networks — surface inside the same hosted checkout as Visa, Mastercard, Apple Pay and bank rails. The buyer picks Pay-With-Wallet; the merchant's back-end sees a normalised authorisation event identical in shape to a card receipt.

  2. 02

    Convert on receipt — or hold the asset

    Conversion-on-receipt is a per-asset policy. Incoming USDC, USDT, BTC or ETH can convert to the merchant's settlement currency at the rail's quote (fiat-only treasury), or land in the merchant's connected wallet as-is. Switching between modes is a dashboard change, not a re-integration.

  3. 03

    Crypto processing on the website without separate plumbing

    There's no separate crypto console, no separate webhook stream, no separate reconciliation feed. Crypto processing on the website rides the same /v1/payments endpoint as every other method — the only difference is `method: crypto` and the asset/network metadata.

  4. 04

    Confirmed = settled — no chargeback window

    A confirmed on-chain transaction has no representment cycle. Refunds remain merchant-initiated; unilateral disputes don't exist on the rail. Operationally that removes a class of revenue leakage entirely — a different reconciliation calendar, not a worse one.

How it works

From wallet tap to a normalised ledger row in five stages

Five concrete stages between the buyer choosing Pay-With-Wallet and the platform writing a ledger row finance closes the month against.

  1. 01

    Buyer picks Pay-With-Wallet

    On the hosted checkout (or the merchant's embedded SDK), the buyer chooses crypto. The platform asks the connected partner gateway for a dynamic address or invoice with the amount and order ID embedded.

  2. 02

    Quote locks for the authorisation window

    When the buyer picks crypto, the gateway quotes the equivalent in the chosen asset and locks the rate. The merchant sees the fiat equivalent throughout — the buyer's wallet sees the asset amount.

  3. 03

    Buyer signs from their wallet

    The buyer scans a QR (or taps Pay in-wallet) and signs the transaction. The connected gateway watches the chain and confirms at the required block depth.

  4. 04

    Settle — converted or as-is

    If conversion-on-receipt is on, the gateway converts the received asset to the merchant's settlement currency at the locked rate. If conversion is off, the asset lands in the merchant's connected wallet.

  5. 05

    Reconcile in the same ledger as card and ACH

    The platform records the authorisation, settlement and any conversion fee on the same ledger row shape as a card receipt — same export, same accounting integration, same operator portal.

Main use cases

Where payment by crypto earns its keep

Six merchant shapes that benefit from a crypto rail, with the operational shape that fits each.

  • E-com

    E-commerce — accept payment in crypto

    Online retailers add a Pay-With-Wallet button next to card and wallet options. Conversion-on-receipt keeps treasury fiat-only; the crypto rail just changes who can pay.

  • B2B

    Cross-border B2B invoicing

    Invoices to overseas counterparties paid in stablecoin clear faster than wire instructions and skip correspondent-bank fees. The invoice and the on-chain receipt share one record in the reconciliation feed.

  • Marketplace

    Marketplaces and per-seller payouts

    Sellers in jurisdictions where stablecoins are a more stable unit of account than the local currency receive payouts in USDC via the same orchestration; the platform reconciles per-seller in the same ledger as fiat payouts.

  • Subs

    Subscriptions on stablecoin pre-funded wallets

    Stablecoin-denominated subscriptions on pre-funded merchant wallets that debit on a schedule. Vault tokens track the customer; renewal lives inside the same orchestration as card retries.

  • ACH

    ACH payment crypto pair flows

    Merchants using ACH for US debit flows can pair them with crypto rails for buyers who prefer stablecoin — the ach payment crypto combination runs through the same authorise endpoint, with the merchant choosing the rail per buyer profile.

  • In-store

    In-store and quick-service

    QR-on-the-till plus a wallet-side confirmation. The terminal hands off to the connected gateway; settlement and reporting are identical to web flow.

Platform features

Capabilities behind crypto processing on the website

What the platform actually ships for crypto rails — beyond the general orchestration features shared with card and bank-rail authorisations.

  • Unified API for payment crypto

    Crypto authorisations run through the same /v1/payments endpoint as cards. One webhook stream, one event model.

  • Partner-licensed crypto gateways

    Crypto rails delivered through licensed partner gateways with the relevant VASP / MiCA-relevant authorisations in supported regions.

  • Asset coverage

    USDC, USDT, DAI, PYUSD, BTC, ETH, SOL, MATIC and others — exact list per merchant depends on the connected gateway's regional licensing.

  • Network coverage

    Base, Arbitrum, Optimism, Polygon, Solana, Tron, Bitcoin Lightning, Stellar — per-asset routing decides which network to use.

  • Conversion-on-receipt

    Per-asset conversion policy converts received crypto to the merchant's settlement currency at the rail's quote — optional, per merchant.

  • Vault tokens for crypto

    The customer's wallet address tokenises to a vault token in the same way a card PAN does — refunds, partial refunds and audit reference the token, not the address.

  • Refund API

    Merchant-initiated refunds via the same refund endpoint as card. The connected gateway issues an on-chain refund to the originating wallet.

  • Webhook event model

    Signed, replay-safe webhook events for authorised / confirmed / settled / refunded — identical shape to card events.

  • Address screening

    Connected gateways run on-chain address screening against sanctions lists; flagged authorisations are rejected at the gateway.

  • Travel-rule support

    Where the connected partner gateway supports the FATF Travel Rule on the relevant rail, the metadata is captured and surfaced in the reconciliation feed.

  • Operator portal

    One dashboard for crypto and fiat: authorisations, refunds and reconciliation across every connected rail.

  • Sandbox parity

    Sandbox crypto flows that mirror production, including chain confirmations and conversion behaviour.

Trust & compliance

Compliance posture for payment crypto on the platform

Crypto rails are delivered through licensed partner gateways; the rest of the posture is inherited from the platform's audited environment.

Partner-licensed crypto rails
Crypto rails are delivered through licensed partner gateways with their own VASP / MiCA-relevant authorisations in the regions they cover.
AML / KYC inheritance
Sub-merchants on the platform inherit the partner-gateway AML / KYC posture; merchant-level KYB happens once during topropay onboarding.
Travel-rule support
Where the connected partner gateway supports the FATF Travel Rule on the relevant rail, the metadata is captured and surfaced in the reconciliation feed.
Sanctions address screening
Connected gateways run on-chain address screening against sanctions lists; flagged authorisations are rejected at the gateway, not in the merchant's surface.
PCI / fiat posture preserved
Adding crypto rails does not affect the platform's PCI DSS Level 1 posture for the fiat side.
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 rail.

Ready to switch on crypto

Payment crypto next to card and ACH on the same API.

A 30-minute review walks through the relevant rails for your buyer base, the conversion-on-receipt policy that fits treasury, and a sandbox to test against before any commercial commitment.

Book a crypto review Read the API docs

Frequently asked

Buyer questions about payment crypto on topropay

Questions buyers ask before committing — what crypto rails surface, how processing works, ACH-vs-crypto pairing, geographies and the refund model.

  1. 01

    What does payment crypto mean on topropay?

    Payment crypto on topropay means accepting a payment in a crypto asset — stablecoin or major token — through the same unified API the merchant already uses for cards and bank rails. The crypto rail is delivered through licensed partner gateways; topropay routes, reconciles and signs the webhook events around it.

  2. 02

    How does payment with crypto look from the buyer's perspective?

    Payment with crypto looks like a Pay-With-Wallet button on the checkout. The buyer picks it, scans a QR (web) or taps Pay (in-wallet), confirms the asset amount in their wallet, and signs. The merchant sees a normalised authorised event in seconds-to-minutes depending on the chosen network.

  3. 03

    How does payment in crypto differ from a card authorisation?

    Payment in crypto carries the on-chain confirmation calendar (seconds on L2s and Lightning; minutes on mainnet BTC; near-instant on Solana), optional conversion-on-receipt, and no chargeback window. A card authorisation carries scheme rules, 3DS / SCA challenges and the chargeback cycle. Both flow through the same API on topropay; the differences are rail mechanics.

  4. 04

    What does accept payment in crypto require on the merchant side?

    Accept payment in crypto requires enabling the crypto method on the merchant contract (a dashboard toggle), picking the assets and networks the merchant wants to accept, and choosing a conversion-on-receipt policy. No separate SDK, no separate console; the merchant's existing back-end keeps handling /v1/payments.

  5. 05

    How does payment by crypto compare to a bank-rail payment?

    Payment by crypto on a stablecoin-on-L2 network typically settles in seconds for a flat per-transaction fee; a bank-rail payment (SEPA / ACH / Bacs) settles in T+1 to T+3 at a different fee profile. The merchant chooses which rail to surface per buyer or per market; the orchestration treats both as methods on the same API.

  6. 06

    Does ach payment crypto pairing work for US merchants?

    Yes — ach payment crypto pairing means surfacing ACH and crypto rails together on the merchant's checkout for US buyers. Some buyers prefer ACH (no card-issuer dependency, low fee), some prefer stablecoin (instant settlement, no chargeback). topropay routes either through the same API; the merchant doesn't fork the integration per rail.

  7. 07

    What does crypto processing look like under the hood?

    Crypto processing on topropay: the connected partner gateway watches the chain for the buyer's transaction, applies the configured block-depth requirement, optionally converts to fiat at the locked rate, and fires a normalised authorised / confirmed / settled webhook stream. The merchant's back-end consumes the same event shape as for card processing.

  8. 08

    What does crypto processing on the website mean for the buyer experience?

    Crypto processing on the website means the buyer sees a Pay-With-Wallet button on the merchant's checkout, completes the transaction in their wallet app, and is redirected back to the merchant's confirmation page when the on-chain confirmation lands. No leaving the merchant's domain except for the wallet-side step; the rest is one seamless flow.

  9. 09

    Are there geographies where payment crypto is not supported?

    Payment crypto is supported where the connected partner gateway holds the relevant VASP / MiCA-relevant authorisations. EU / UK markets are broadly covered; US coverage is state-specific; some APAC markets require additional partner-side licensing. The platform's compliance team confirms eligibility during onboarding.

  10. 10

    How is the partner-gateway model different from running crypto in-house?

    Running crypto in-house means the merchant runs its own wallet infrastructure, key management, address screening, AML monitoring and licensing. The partner-gateway model collapses that into a single dependency — the partner gateway carries the licensing and the operational posture; topropay routes and reconciles around it.

  11. 11

    What's the fee profile for payment crypto?

    Payment crypto fee profile: the connected partner gateway charges a per-transaction fee (typically lower than card interchange + scheme fees on small tickets, comparable on larger), plus topropay's per-authorisation platform fee. Conversion-on-receipt carries an FX spread set by the rail. Sandbox is free.

  12. 12

    Can refunds on payment in crypto be reversed?

    Refunds on payment in crypto are merchant-initiated and irreversible once on-chain. The connected gateway issues a return transaction to the originating wallet; once the network confirms, the refund is final. Partial refunds are supported. Audit logs retain the refund operator, reason and on-chain transaction IDs.

  13. 13

    How does this page relate to the broader crypto-payments overview?

    This page focuses on the action verbs (payment with crypto, accept payment in crypto, payment by crypto) and how each maps to the platform's behaviour. The /crypto-payments/ sibling page covers the wider business view — strategy, use cases at scale and rail comparisons. Both share the same underlying engine.

  14. 14

    Is there a difference between a crypto payment gateway and crypto processing?

    A crypto payment gateway is the surface that authorises a single crypto payment (the API plus the buyer-side flow). Crypto processing is the back-end work behind it — chain watching, confirmation handling, settlement and reconciliation. On topropay both sit behind the unified API; the merchant doesn't see the seam.

  15. 15

    Can a merchant test the full payment crypto flow without going live?

    Yes. The sandbox supports the full payment crypto flow — dynamic invoice / address generation, simulated bank-confirmation / chain-confirmation outcomes (success, pending, expired, failed), webhook replay, refund-flow testing. Error model is identical to production.

Related

Related on the topropay platform