Crypto payment processor

Crypto payment processor — fiat in, fiat out, crypto in the middle.

topropay's orchestration layer puts licensed partner crypto gateways behind one unified API. Stablecoins, majors and L2 networks all route through it. Amounts are quoted in fiat and locked at checkout. Convert on receipt where you want it, and every payment lands in one ledger alongside card and bank-rail receipts.

Book a crypto-processor review Read the API docs
Checkout €189.00 FIAT
On-chain 189.00 USDC CRYPTO · Base
Settled €189.00 FIAT · merchant ledger
Buyer pays in stablecoin, merchant receives in fiat.
200+
supported tokens via partner gateways
<1m
typical L2 stablecoin confirmation
Auto
fiat-on-receipt conversion policy
1 ledger
crypto and fiat normalised together

Key benefits

Why an orchestrated crypto processor wins on every axis

Four outcomes that show up once a multi-rail crypto processor sits behind one unified API. No separate console. No separate ledger.

  1. 01

    One crypto payment processor surface, many connected rails

    Behind the crypto-method tile on the merchant's checkout sits a panel of licensed partner crypto gateways. Stablecoins on L2 networks, BTC on Lightning, ETH on mainnet — each rail surfaces through one unified API. The merchant doesn't pick a single crypto processor; the platform routes per asset and per chain.

  2. 02

    Fiat-on-receipt or crypto-on-balance — merchant's choice

    A fiat to crypto payment processor flow converts the merchant's incoming crypto to settlement currency at the rail's quote, on receipt. A crypto-to-fiat or crypto-to-balance flow leaves the asset in the merchant's connected wallet. The choice is per-asset configuration, not a separate integration.

  3. 03

    Same API as card — no separate crypto SDK

    Crypto authorisations call the same /v1/payments endpoint as cards, with `method: usdc / btc / eth / ...`. The webhook event model is identical; vault tokens identify the customer across rails; refunds operate on the same surface. Creating crypto payment processor functionality on an existing card stack is a configuration step, not a new SDK install.

  4. 04

    One reconciliation feed for crypto and fiat receipts

    Settlements from crypto rails and from card / bank-rail providers normalise into one ledger keyed off vault tokens. Daily exports drop into ERP or warehouse with method-tagged rows — the finance team treats crypto receipts the same way as card receipts.

How it works

From buyer wallet to a normalised reconciliation row in five stages

Five stages take the buyer from picking crypto at checkout to a normalised ledger row in finance's daily export. Most of them run in seconds.

  1. 01

    Buyer picks crypto at checkout

    The hosted checkout (or embedded SDK) surfaces a Pay-With-Wallet option alongside cards. The buyer picks an asset and a chain; the connected partner gateway generates a payment intent with locked amount.

  2. 02

    Quote and lock the rate

    For fiat-denominated checkouts, the gateway quotes the equivalent in the chosen asset and locks the rate for the authorisation window. The merchant sees the fiat figure throughout; the on-chain amount adjusts to match.

  3. 03

    Buyer signs from their wallet

    The buyer scans the QR or taps Pay in-wallet (Metamask, Phantom, hardware wallets, Lightning wallets, etc.). The connected gateway watches the chain and confirms at the required block depth — seconds on L2s, longer on mainnet Bitcoin without Lightning.

  4. 04

    Convert or hold per merchant policy

    On confirmation, the rail converts to the merchant's settlement currency at the locked rate (fiat-on-receipt) or credits the asset to the merchant's connected wallet (crypto-on-balance). Per-asset, per-merchant policy choice.

  5. 05

    Reconcile alongside card receipts

    The platform surfaces the authorisation, settlement and any conversion fee in the same normalised ledger as card receipts — same export, same accounting integration.

Main use cases

Where a best crypto payment processor setup earns its keep

Six merchant shapes that share the same orchestration layer but stress the crypto processor differently — DTC, subscriptions, marketplaces, B2B, travel and licensed gaming.

  • DTC

    Crypto payment processor for business — DTC and online retail

    DTC brands add a Pay-With-Wallet button next to cards. Conversion-on-receipt keeps the balance sheet fiat-only; the rail just changes who can pay. The crypto payment processor for business shape is identical to card-side fulfilment from finance's perspective.

  • Subs

    Subscriptions denominated in stablecoin

    Stablecoin-denominated subscriptions on wallets that support recurring authorisations, or pre-funded merchant-wallet debits on a schedule. Vault tokens track the customer; renewals share the same recurring engine as card-on-file.

  • Plat

    Marketplaces and platform payouts

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

  • 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.

  • Travel

    Travel and high-ticket

    High-ticket orders see disproportionate FX and interchange cost on cards — a stablecoin lane absorbs that for buyers who want it, without forcing card buyers off cards.

  • Game

    Licensed gaming and digital goods

    Licensed operators in permitted jurisdictions surface stablecoin and major-token authorisations alongside card. The crypto processor side runs through the same orchestration; operator-specific risk rules and method bias sit on top.

Platform features

Capabilities behind the fiat to crypto payment processor surface

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

  • Connected partner crypto processors

    Licensed partner crypto gateways behind the unified API; the platform routes, abstracts and reconciles.

  • Fiat-to-crypto payment processor flow

    Fiat-denominated checkout converted to the chosen asset at quote time; merchant sees fiat amount throughout.

  • Crypto-to-fiat conversion-on-receipt

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

  • Unified payments API

    Crypto authorisations call the same REST contract as cards; one webhook stream, one event model.

  • Per-chain routing

    Route stablecoins on low-fee L2s, BTC on Lightning, ETH on mainnet — from the dashboard, not a new integration.

  • Wallet support

    Hosted Pay-With-Wallet flows; QR generation for in-store; deep-links for in-app; copy-paste address fallback.

  • Tokenised customer record

    Vault tokens identify the customer across rails; refunds, partial refunds and recurring share one customer view.

  • Refund API

    Merchant-initiated refunds via the same refund endpoint as card; gateway-side return-transaction handling on the relevant chain.

  • Webhooks & event stream

    Signed, normalised webhooks for authorised / confirmed / settled / refunded events into your SIEM, warehouse or in-house tooling.

  • Operator portal

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

  • Sandbox parity

    Sandbox crypto flows that mirror production, including chain confirmations, fiat-quote behaviour and refund scenarios.

  • Audit log

    Operator actions, conversion events and refund operations logged with timestamp and actor identity.

Trust & compliance

Compliance posture for a crypto payment processor

Crypto rails carry their own regulatory shape. The platform rides partner-licensed gateways with the relevant authorisations, and inherits the associated AML / KYC controls on the merchant's behalf.

Partner-licensed crypto rails
Crypto rails are delivered through licensed partner gateways with VASP / MiCA-relevant authorisations in the regions they cover.
AML / KYC inheritance
Sub-merchants 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.
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 wire crypto

Add a crypto rail to your checkout — fiat in, fiat out.

A 30-minute crypto-processor review walks through the partner gateways for your buyer base, the conversion policy that fits treasury, and a sandbox to test against before any commercial commitment.

Book a crypto-processor review Read the API docs

Frequently asked

Buyer questions about crypto payment processor on topropay

Questions buyers ask before committing — fiat-to-crypto flow, refunds, volatility, chargebacks, regional availability and how the crypto side fits with card.

  1. 01

    What does topropay mean by crypto payment processor?

    Crypto payment processor on topropay is the orchestration layer that authorises, settles, refunds and reconciles crypto authorisations — through licensed partner crypto gateways. The merchant integrates against the unified API; the platform handles the per-chain routing, the gateway-side messaging and the per-asset settlement reporting.

  2. 02

    Is topropay itself a crypto processor?

    topropay is not a direct crypto processor in the regulatory sense — crypto rails are delivered through licensed partner crypto gateways, and the relevant VASP / MiCA-style licences sit with those partners. topropay orchestrates the connected panel and exposes one unified API in front of it.

  3. 03

    What's typically the best crypto payment gateway behind topropay's orchestration?

    Best crypto payment gateway depends on the merchant's traffic — geography, asset mix, average ticket and treasury policy. For high-volume stablecoin merchants the best crypto payment gateway is usually an L2-focused processor; for merchants accepting BTC, a Lightning-aware processor wins. topropay routes per asset and per chain; the merchant doesn't lock to one provider.

  4. 04

    Does the platform support a fiat to crypto payment gateway flow?

    Yes. A fiat to crypto payment gateway flow on topropay surfaces a fiat-denominated checkout (e.g. €189.00) and converts to the chosen crypto asset at the rail's quote on payment. The buyer pays in crypto; the merchant sees fiat throughout. Conversion-on-receipt policies can also convert the received crypto back to fiat for the merchant's settlement account.

  5. 05

    What does a fiat to crypto payment processor on topropay look like end-to-end?

    End-to-end fiat to crypto payment processor flow: merchant prices in fiat → connected gateway quotes the equivalent in chosen asset and locks rate → buyer signs from wallet → on-chain confirmation triggers normalised authorised event → conversion-on-receipt converts to merchant's settlement currency (if enabled). The integration is the same /v1/payments endpoint as a card authorisation.

  6. 06

    What does crypto payment processor for business actually deliver?

    Crypto payment processor for business on topropay delivers a unified surface for accepting crypto alongside card, with conversion policies that keep treasury simple, reconciliation that lands in the same ledger as card receipts, and operator tooling that doesn't require a separate console. The merchant runs crypto as another method, not as a separate product line.

  7. 07

    What's the best crypto payment processor for a multi-asset merchant?

    Best crypto payment processor for a multi-asset merchant is rarely one provider — it's a panel where the right partner gateway runs each asset on its native chain. topropay's orchestration handles the per-asset routing decisions, so the merchant doesn't need to evaluate processors individually.

  8. 08

    How is creating crypto payment processor functionality different from creating a card processor integration?

    Creating crypto payment processor functionality on topropay is mostly identical to a card integration — same authorise endpoint, same webhook model, same vault. The differences are at the configuration layer: which assets and chains are enabled, what the conversion-on-receipt policy is per asset, what the dunning / refund-window expectations are for chain-finality rather than card-cycle behaviour.

  9. 09

    How does the crypto processor handle refunds?

    Refunds are merchant-initiated via the same refund endpoint as card. The connected partner gateway initiates a return transaction to the originating address on the relevant chain; refunds clear at chain-confirmation speed (seconds on L2s, longer on mainnet without Lightning). Partial refunds are supported. The refund operation logs the actor, reason and the on-chain reference.

  10. 10

    How does the platform handle volatility on non-stablecoin assets?

    Volatility on non-stablecoin assets (BTC, ETH) is handled by the rate-lock window on quote — the merchant sees the fiat figure, the rail quotes the equivalent in the asset for a bounded window, and the locked rate applies on confirmation. Outside the window the quote refreshes. For merchants who don't want volatility on receipt, conversion-on-receipt to fiat is on by default.

  11. 11

    Is crypto payment processing available everywhere?

    Crypto payment processing is available in the regions where the connected partner crypto gateways hold the relevant authorisations. In the EU and UK that typically means MiCA / FCA-aligned providers; in APAC and LATAM it varies by country. topropay's onboarding flags the relevant constraints during scoping so the merchant doesn't go live on a rail that's not legally clean for their setup.

  12. 12

    Are there chargebacks on crypto processor authorisations?

    Confirmed on-chain transactions don't carry a card-style chargeback window — once settled, settled. Refunds are merchant-initiated; unilateral disputes don't exist on the rail. Operationally that's a different reconciliation calendar, but on net it removes a class of revenue leakage that card carries.

  13. 13

    How is the crypto payment processor priced?

    Crypto payment processor pricing on topropay is per-authorisation on top of the partner-gateway fee — no platform retainer, no monthly minimum. Gateway fees vary by asset and chain (Lightning BTC and L2 stablecoins are typically lower than mainnet BTC or ETH). Conversion-on-receipt carries the rail's quote spread; the platform fee is a separate line.

  14. 14

    Does the crypto processor support staking, lending or any non-payment crypto activity?

    No — topropay's crypto processor scope is payments only: authorise, settle, refund. Staking, lending, custody-as-a-service or other DeFi activity is out of scope. Merchants who need those flows integrate them through dedicated providers; topropay's role is the payment-acceptance and reconciliation layer.

  15. 15

    How is the crypto processor tested before going live?

    The sandbox covers the full crypto flow: dynamic QR generation, simulated bank-side wallet flows, deterministic chain-confirmation outcomes (success, pending, expired, failed), webhook replay, refund-flow testing. The error model is identical to production; merchants build the full integration against the sandbox before any commercial commitment.

Related

Related on the topropay platform