Meso
- Name: Meso
- URL: https://meso.network/
- Category: bank-to-wallet payments operator / embedded transfer and KYC workflow company / origin-allowlisted ramp operator
- Tags: ethereum-ecosystem solana-ecosystem
- Summary: Meso belongs in
companies/because the durable dependency is not only a browser SDK. It is a named operator that admits partners into a private-beta integration flow, requires origin registration, issues thepartnerId, runs KYC and identity verification, debits users’ bank accounts, chooses which wallet-verification path is acceptable, and publishes the transfer lifecycle the host app is expected to trust. The useful question is not justhow does the SDK launch a transfer?butwhich company controls onboarding, wallet-verification policy, bank-debit origination, and transfer-state truth behind that flow? - What it does:
- Operates bank-to-wallet fiat-to-crypto transfer infrastructure for partner wallets, dapps, and traditional web apps rather than a generic public checkout widget
- Requires a Meso partner account and onboarding flow where the partner declares its application origin and receives a company-issued
partnerId - Runs user onboarding, including KYC checks, identity verification, bank-account debits, and crypto delivery to the specified wallet address
- Exposes wallet-verification choices including standard wallet verification, headless wallet verification, and bypassed wallet verification inside the partner integration surface
- Publishes lifecycle events such as ready, transfer approved, transfer complete, close, configuration errors, and unsupported network or asset errors that downstream apps are expected to consume
- Ships browser SDK and iOS WebView reference materials while explicitly saying there is no official iOS SDK, which keeps the mobile integration path inside the same named company shell
- Key claims:
- The homepage describes Meso as
Payment infrastructure designed for crypto, while the verified GitHub org describes it asThe fast and safe way to transfer money between wallets and banks, which is already operator-shell language rather than a pure protocol claim - The
meso-jsREADME says Meso handles user onboarding, KYC, identity verification, bank-account debits, and crypto transfers to the specified wallet address, which makes the company the real workflow boundary behind the embedded product - The same README says integrations require a Meso partner account, an approved origin, and a
partnerId, and says the SDK is currently in private beta reachable viasupport@meso.network, which is a clean sign that production access is company-gated rather than an open rail - The SDK docs expose environment selection, CSP requirements, supported network and asset enums, and event callbacks, showing that policy over origin admission and transfer-state publication sits with the company rather than only in app-side code
- The iOS example README says Meso does not have an official iOS SDK and instead demonstrates a WebView-based reference implementation, which reinforces that even the mobile path is a company-shaped integration shell rather than a neutral standard
- Both browser and iOS materials make wallet-signing and transfer-state handling part of the integration contract, so the named operator becomes part of the practical trust perimeter between user bank debit and wallet funding
- The homepage describes Meso as
- Whitepaper: No classic standalone company whitepaper is the important artifact here. The clearest primary materials are the Meso homepage, verified GitHub org,
meso-jsSDK docs, and the iOS reference implementation already captured in../whitepapers/meso-primary-sources-2026-04-27.mdplus the current live source refresh. - Sources:
Internal linkages
- Product-layer note: meso.
- Useful adjacent company reads: transak, ramp-network, and moonpay.
- Routing-layer contrast above any single provider shell: onramper.
Protocol / company boundary
- meso should stay on the product-layer integration mechanics: SDK launch shape, wallet-verification callbacks, transfer events, supported environments, and the host-app wiring needed to embed the bank-to-wallet flow.
- This company note isolates the broader operator shell: partner admission, private-beta access, origin registration,
partnerIdissuance, KYC and identity workflow, bank-debit origination, supported network and asset policy, and transfer-state publication all sit with Meso as a named company. - That split matters because the dependency an app inherits is not a neutral banking bridge. It is a company-managed workflow graph spanning onboarding, verification, debit origination, and lifecycle truth.
Control surface
-
Practical leverage sits in partner admission, support-mediated beta access, approved-origin registration,
partnerIdissuance, sandbox-versus-production environment access, supported network and asset coverage, wallet-verification mode, KYC and identity checks, bank-debit initiation, and the event lifecycle partners trust when transfer state is disputed. -
The sticky dependency is workflow memory: once a wallet or app hardens around Meso-managed onboarding, verification callbacks, debit handling, and transfer events, the real lock-in is to the company-run payments and identity shell rather than only to a browser SDK.
-
Read Meso as a company-operated bank-to-wallet funding control plane first, and as an embeddable transfer SDK second.
-
Last reviewed: 2026-08-11 UTC