Cowrie Research

mesh

5 min read

Mesh

  • Name: Mesh
  • URL: https://www.meshpay.com/
  • Category: crypto-payments connectivity company / hosted transfer-orchestration operator / managed-auth-token and webhook-truth shell
  • Tags: ethereum-ecosystem solana-ecosystem
  • Summary: Mesh belongs in companies/ because the sticky dependency is not only what SDK or API do I call? but which named operator decides which exchanges and wallets are supported, issues the short-lived session tokens, manages reusable account-auth state, intermediates login / MFA / compliance steps, and signs the webhook events downstream apps use as final transfer truth? mesh stays the product-layer note for Link Token mechanics, SDK callbacks, and transfer flow shape. This note is for the company boundary where integration admission, hosted account connectivity, token lifecycle handling, and webhook-backed operational truth sit together.
  • What it does:
    • Runs a hosted account-connectivity and transfer-orchestration stack for crypto pay, deposit, and verification flows across wallets and exchanges
    • Operates the Mesh Link SDK and backend flow in which every session begins with a server-side Link Token request that configures transfer type, destination, amount constraints, supported assets/networks, and related session policy
    • Maintains the integration catalog, user-authentication handling, MFA/compliance steps, and the UX shell that takes over once an app launches Link
    • Stores and manages Mesh Managed Token lifecycles on behalf of integrators so returning users can skip full re-authentication and apps can reuse account connectivity through a persistent tokenId
    • Publishes webhook-signed transfer-status events that merchants and apps are expected to treat as the final source of truth for completion rather than trusting client callbacks alone
    • Packages broader payment positioning on top of that hosted shell, including exchange-and-wallet sourced payments, deposits, and settlement into stablecoins or local currency
  • Key claims:
    • Mesh markets itself as the first global crypto payments network, but its own docs read more concretely as a company-run account-connectivity and transfer-orchestration layer sitting between apps and users’ existing wallet/exchange accounts
    • The How it all fits together docs say every Mesh session starts with a server-side POST /api/v1/linktoken call and that the Link Token configures the full user session while remaining short-lived and single-use, which makes session issuance a real operator surface rather than just a UI detail
    • The same docs say that once Link launches, Mesh handles the integration catalog, authentication flows, transfer preview, compliance steps, and success/error states, which is the clearest signal that the user-facing account-connection shell is hosted and operator-run
    • The return-user docs say Mesh Managed Tokens securely store and manage token lifecycles on your behalf and that Mesh handles token refresh logic while integrators keep a persistent tokenId, which is strong evidence that reusable connectivity depends on a named offchain operator rather than only a neutral client SDK
    • The transfer-status docs say businesses should not rely on onTransferFinished for finality and should instead use Mesh webhooks, which Mesh signs with HMAC-SHA256; the same docs note only one production and one sandbox callback URI can be registered at a time and that webhooks may be retried, reinforcing that transfer truth is published through a company-managed delivery surface
    • Mesh’s docs also require webhook recipients to trust Mesh’s static source IP and secret-managed signature flow, which makes the operator boundary explicit for anyone treating Mesh events as settlement or inventory-release truth
  • Whitepaper: No classic standalone Mesh company whitepaper is the point here. The primary materials that matter are Mesh’s official site plus the docs describing Link Token issuance, hosted SDK flow, Managed Token lifecycle handling, and webhook-confirmed transfer truth.
  • Sources:

Internal linkages

  • Product-layer note: mesh.
  • Useful adjacent company reads: coinflow, halliday, and bridge-xyz.
  • Reusable lens: account-connectivity vendors deserve a separate company cut when supported-integration admission, reusable auth state, and webhook-backed business truth sit behind one named operator.

Protocol / company boundary

  • Keep mesh focused on the product mechanics: Link Tokens, SDK launch, callbacks, managed-account-token reuse, webhook integration shape, and the Pay / Deposit / Verify flow decomposition.
  • Keep this note focused on the operator shell above that product: integrator onboarding, supported exchange and wallet coverage, hosted login / MFA / compliance flow, token-lifecycle handling, webhook endpoint registration, and the delivery of final transfer-status truth.
  • That split matters because how does Mesh Link work? and which company controls the reusable account-connection and webhook-truth boundary my app is trusting? are related but different questions.

Control surface

  • Practical authority sits in integration admission, Link Token issuance, supported-network and supported-platform coverage, managed-token lifecycle handling, hosted auth/compliance steps, webhook-secret and callback-URI configuration, and the publication of Succeeded or Failed transfer outcomes that downstream apps use for business decisions.

  • The sticky dependency is not only the embedded widget or client SDK. It is the company-run shell that decides which external accounts can be connected, how long that connectivity persists, what post-authentication flow users experience, and which signed events a merchant credits as real completion.

  • Read Mesh as a company-operated account-connectivity and transfer-truth control plane, not as a neutral payment network.

  • Last reviewed: 2026-08-10 UTC

Graph View

Backlinks