depay-company-primary-sources-2026-08-13

DePay company-boundary primary sources — 2026-08-13

Why this source capture exists

• Earlier corpus work already had a solid product-layer note for depay.
• This pass was about whether DePay also deserves a separate companies/ note.
• The answer is yes, but only for the managed integration and operator shell above the payment widget / protocol surface: DePay AG, centralized-service licensing, account-level integrations, callback-signing keys, domain restrictions, and the legal/privacy perimeter.

Primary-source snapshots

1) Official homepage

• URL: https://depay.com/
• Key excerpt:
  • The homepage presents DePay as a Crypto Payments Platform and says teams can use DePay’s software, infrastructure, and APIs to manage payments on blockchains.
  • It highlights embeddable payments, multichain support, and wallet connectivity, which keeps the product surface clear.
  • For company-taxonomy purposes, the useful point is that the homepage already blends software, infrastructure, and APIs into one named vendor shell rather than presenting only a neutral protocol primitive.

2) Terms and Conditions

• URL: https://depay.com/legal/terms
• Key excerpt:
  • The current terms say the agreement is between the customer and DePay AG, a company incorporated and registered in Switzerland, which establishes a clean legal-entity boundary.
  • The same document says DePay is a technology services provider, not a financial intermediary, and not a payment processor, while also saying that regulated banking or money-transmission services, if present, are handled by licensed affiliates or partner institutions.
  • The terms also distinguish free, basic, open-source software from centralized services and products and say end-user licenses for centralized services apply on a per wallet address/account basis.
  • That split is the strongest current reason to keep a separate company note: part of the stack is open-source payment tooling, but another part is a company-run integration and licensing shell.

3) Privacy Policy

• URL: https://depay.com/privacy
• Key excerpt:
  • The privacy policy names DePay AG as the Owner and Data Controller and gives a Swiss corporate address and company number.
  • It says the application can collect wallet addresses, assets, tokens, balances, usage data, and account/contact information.
  • This matters because even if payment settlement is direct wallet-to-wallet, the wider service shell is still a named company-operated data and account boundary.

4) Widget integration docs

• URL: https://depay.com/docs/payments/integrate/widget/
• Key excerpt:
  • The docs require users to create integrations at https://app.depay.com/dev/integrations and select a managed Payment Widget integration.
  • Merchants configure accepted tokens/blockchains, receiving addresses, redirects, callbacks, events, and optional dynamic-configuration endpoints.
  • Callback and event delivery semantics are company-shaped: DePay retries failed deliveries for roughly 21 days and says callbacks control payment flow.
  • The docs also say DePay signs requests with RSA-PSS via an x-signature header and provides an integration-specific public key for verification.
  • This is exactly the kind of offchain operator shell that belongs in companies/ even when the payment execution itself is non-custodial.

Working conclusion

DePay should remain a real project-layer note because the payment widget, protocol/router mechanics, supported wallet standards, and token-conversion behavior are analytically useful on their own. But it also deserves a company note because the live merchant workflow can depend on DePay AG’s managed integrations, public-key-and-signature trust model, callback/event delivery semantics, domain restrictions, centralized-service licensing, and the legal/privacy shell surrounding those services.