Mercuryo

• Name: Mercuryo
• URL: https://www.mercuryo.io/
• Category: payments and ramp operator / wallet-and-card middleware company / embedded fiat-crypto workflow operator
• Tags: ethereum-ecosystem
• Summary: Mercuryo belongs in companies/ because the durable dependency is not just an on-ramp widget or one virtual-card feature. It is a named company that onboards partners into its API surface, decides which KYC tier and IBAN workflow a user must clear before using different fiat rails, packages wallet creation and fiat-balance objects for partners, and controls the card-and-spend shell many downstream apps inherit by default. The useful question is not just can a user buy or sell here? but which company controls the wallet, KYC, fiat-balance, IBAN, card, and payout workflow graph behind the integration?
• What it does:
  • Operates embedded fiat-to-crypto and crypto-to-fiat flows for wallets and apps through widgets, wrappers, SDKs, and API integrations
  • Packages a broader wallet-and-payments shell where users can create Mercuryo wallets, hold fiat balances, and run buy, sell, top-up, and withdrawal operations through partner-integrated surfaces
  • Gates specific capabilities through company-run KYC tiers, including base KYC for card and bank-transfer crypto flows and KYC2 for IBAN-linked operations
  • Exposes BAAS and partner APIs for user wallets, transaction monitoring, fiat balances, and IBAN creation while requiring Mercuryo-issued partner tokens and bearer-token auth
  • Sells Mercuryo Spend as a virtual-card product linked to connected crypto wallets, which keeps card issuance and spend workflow inside the same named company shell as the ramp and wallet stack
  • Publishes mobile SDK and widget-wrapper tooling so partner apps can inherit Mercuryo-managed auth, wallet, card, and operations flows instead of building their own regulated payment workflow
• Key claims:
  • Mercuryo’s homepage markets the company as the payment engine behind top web3 business, says it has supported 12M people onboarding to web3 since launching in 2018, and groups the stack into On-Ramp plus Spend rather than a single checkout widget
  • The same homepage advertises support across 150+ countries, 10+ payment methods, 70+ cryptocurrencies, and instant issuance for virtual co-branded cards, which is analytically useful because several operator-controlled payment surfaces sit under one company boundary
  • The BAAS/API README says Mercuryo API is built around crypto and fiat balances, lets partner users create Mercuryo wallets, and expects the integrating service to monitor user transactions and its own revenue inside the Mercuryo workflow shell
  • That BAAS/API README also says partners need a Mercuryo manager to obtain the sdk-partner-token, that B2B methods require bearer-token signing, and that KYC / KYC2 status governs which card, bank-transfer, and IBAN actions users may perform, which is exactly why the entity boundary matters more than a generic ramp label
  • The BAAS/API docs make the EU-only IBAN branch explicit and enumerate transaction types across buy-card, buy-invoice, buy-IBAN, sell-card, fiat deposit, and fiat withdrawal flows, showing that Mercuryo is operating a real money-movement workflow rather than a thin redirect layer
  • The iOS SDK README says Mercuryo provides a platform for developers to create their own services on top of the API and highlights authentication, wallets, operations, and cards as first-class integration modules, reinforcing that partners inherit a company-run app-and-payments shell rather than only a buy button
• Whitepaper: No classic standalone company whitepaper is the important artifact here. The clearest primary materials are Mercuryo’s homepage plus the BAAS/API and SDK documentation surfaces already captured in ../whitepapers/mercuryo-primary-sources-2026-04-27.md.
• Sources:
  • https://www.mercuryo.io/
  • https://github.com/mercuryoio
  • https://github.com/mercuryoio/BAAS-API
  • https://raw.githubusercontent.com/mercuryoio/BAAS-API/master/README.md
  • https://raw.githubusercontent.com/mercuryoio/iOS-SDK/main/README.md

Internal linkages

• Product-layer note: mercuryo.
• Useful adjacent company reads: moonpay, transak, and ramp-network.
• Routing-layer contrast where the question shifts toward provider aggregation rather than one operator shell: onramper.

Protocol / company boundary

• mercuryo should stay focused on the partner-integrated product surface itself: embedded ramp behavior, wallet and balance objects, card-facing SDK modules, and the transaction flows apps actually wire into.
• This company note isolates the broader operator shell: partner-token issuance, bearer-auth workflow, KYC-tier policy, IBAN eligibility, wallet creation, fiat-balance handling, card packaging, jurisdiction coverage, and support truth all sit with Mercuryo as a named company.
• That split matters because the dependency most integrators inherit is not a neutral fiat bridge. It is a company-managed workflow graph spanning onboarding, authentication, KYC state, card issuance, fiat balances, and payout behavior.

Control surface

• Practical leverage sits in partner admission, token issuance, KYC and KYC2 policy, EU-only IBAN exposure, wallet creation, fiat-balance semantics, card issuance and spend packaging, supported payment methods, payout behavior, and the company-run API and support surfaces partners trust when state is disputed.

• The sticky dependency is operational memory: once a wallet or app hardens around Mercuryo-managed auth, wallet objects, balance handling, KYC progression, IBAN creation, and card flows, the real lock-in is to the company-run payment and identity shell rather than only to a checkout widget.

• Read Mercuryo as a company-operated wallet, ramp, and card-workflow control plane first, and as an on/off-ramp product second.

• Last reviewed: 2026-08-08 UTC