Cowrie Research

depay

5 min read

DePay

  • Name: DePay
  • URL: https://depay.com/
  • Category: wallet-to-wallet payments company / checkout-integration operator / managed callback-and-integration-control shell
  • Tags: ethereum-ecosystem solana-ecosystem
  • Summary: DePay belongs in companies/ because the sticky dependency is not only what widget or protocol can route a payment? but which named operator runs the managed integration shell, issues integration IDs and callback-signing keys, enforces domain restrictions, sells centralized end-user licenses, and publishes the callback / event truth merchants may end up wiring into fulfillment systems? depay stays the product-layer note for route selection, token conversion, wallet standards, and merchant checkout mechanics. This note is for the DePay AG boundary where dashboard access, integration policy, signing keys, legal/privacy terms, and the hosted coordination layer accumulate.
  • What it does:
    • Runs DePay’s account and integration shell around wallet-to-wallet checkout, including app.depay.com-managed integrations for widgets, callbacks, events, redirects, and dynamic configuration endpoints
    • Issues integration-specific public keys and signs callback/event traffic so downstream systems can verify that webhook-style messages really came from DePay’s backend
    • Controls domain restrictions, callback URLs, event endpoints, retry behavior, and the managed flow merchants inherit when they use DePay-hosted integrations instead of only local open-source components
    • Distinguishes between free MIT-licensed open-source software and separate centralized services and products, including per-wallet/account end-user licenses for those centralized surfaces
    • Presents itself as a software provider rather than a financial intermediary, while stating that licensed affiliates or partner financial institutions would handle any regulated money-transmission or banking-style services
    • Acts as the data controller for the broader site / platform / services shell, including wallet-address, balance, and usage-data handling described in the public privacy policy
  • Key claims:
    • The current terms say the agreement is between the customer and DePay AG, a Switzerland-incorporated company, which is the clearest reason the entity boundary matters separately from the checkout widget or protocol docs
    • Those same terms say DePay is a technology services provider, not a financial intermediary, and not a payment processor, while also saying that if regulated services are provided they are handled by licensed affiliates or partner institutions; that is a real operating-boundary claim, not just branding
    • The terms explicitly distinguish free MIT-licensed open-source software from centralized services and products and say end-user licenses for centralized services apply on a per wallet address/account basis, which is a strong signal that the company layer is doing meaningful work above the open product surface
    • The widget docs require merchants to create integrations in app.depay.com, configure accepted chains/tokens and receiving addresses, set callback and events endpoints, and optionally provide dynamic-configuration URLs that must answer within two seconds; that makes managed configuration a real operator surface rather than a minor convenience
    • The same docs say DePay signs requests with RSA-PSS and an x-signature header, provides a public key per integration, and retries failed callback/event deliveries over roughly 21 days, which means merchants can end up treating a company-run delivery system as operational payment truth
    • The privacy policy names DePay AG as owner and data controller and says the application can collect wallet addresses, assets, token balances, usage data, and related account information, reinforcing that the broader platform shell is company-shaped even when settlement itself is wallet-to-wallet
  • Whitepaper: No classic standalone company whitepaper is the point here. The most useful current primary-source snapshot is ../whitepapers/depay-company-primary-sources-2026-08-13.md, which preserves the legal/operator split between DePay’s open payment tooling and its managed company-run integration shell.
  • Sources:

Internal linkages

  • Product-layer note: depay.
  • Useful adjacent company reads: coinflow, mesh, and onramper.
  • Reusable lens: a non-custodial payments brand can still deserve a company note when integration credentials, callback truth, domain restrictions, and centralized-service licensing sit behind one named operator.

Protocol / company boundary

  • Keep depay focused on the payment surface: wallet-to-wallet checkout, multichain accepted-asset policy, token-conversion routes, merchant plugins, and the protocol/router mechanics developers or merchants directly integrate.
  • Keep this note focused on the operator shell above that surface: account and dashboard access, managed integrations, legal/privacy terms, centralized-service licensing, callback-signing keys, retry semantics, domain restrictions, and any partner-mediated regulated-service perimeter.
  • That split matters because how does DePay route a payment? and which company controls the managed integration and webhook-truth shell around that payment? are related but not identical questions.

Control surface

  • Practical authority sits in who gets access to managed integrations, which domains and callback endpoints are accepted, how callback/event authenticity is defined and retried, which centralized services require licenses, how quickly dynamic-configuration endpoints must answer, and whether DePay or an affiliate / partner sits in the surrounding regulated-service lane.

  • The sticky dependency is not only the widget or protocol contract path. It is the company-run coordination shell that can define integration policy, publish signed post-payment messages, suspend access, and shape which parts of the stack are truly open versus operationally gated.

  • Read DePay as a company-operated checkout-control shell layered above non-custodial payment routing, not as a neutral payment rail.

  • Last reviewed: 2026-08-13 UTC

Graph View

Backlinks