Cowrie Research

anypay

4 min read

Anypay Inc.

  • Name: Anypay Inc.
  • URL: https://github.com/anypay/anypay
  • Category: merchant checkout company / payment-request normalization operator / invoice, redirect, and webhook workflow shell
  • Tags: bitcoin-ecosystem
  • Summary: Anypay clears the bar for an entity note because the useful question is not only which payment-request formats does this checkout stack speak? but which named operator maintains the invoice namespace, decides the supported chain and token matrix, ships the official server / SDK / widget surfaces, and becomes the source of redirect and webhook workflow truth around those payment requests? The practical leverage is company-shaped even when the marketing language stresses peer-to-peer and non-custodial payments.
  • What it does:
    • Operates a merchant-facing payment-request and invoice stack spanning server software, SDKs, wallet-compatible client tooling, and checkout widgets
    • Maintains official support for multiple payment-request formats including JSON Payment Protocol, BIP70, BIP270, and Anypay’s own pay:// layer
    • Packages invoice-driven checkout behavior around redirect URLs, webhook callbacks, shared-secret verification, and merchant metadata rather than leaving merchants with only raw addresses
    • Decides which chains, native assets, and stablecoin variants are normalized inside the official Anypay surface
    • Publishes both self-hostable server software and branded hosted-style integration paths like Anypay invoice URLs and the official checkout widget, which is exactly why the company boundary matters
  • Key claims:
    • The main README markets Anypay as Peer to Peer Payments APIs for Developers and says it was created to solve retail-payment problems such as incorrect amounts, invalid addresses, long delays, failure to confirm, double-spend fraud, and accidental double payments
    • That same README says Anypay implements JSON Payment Protocol, BIP70, BIP270, and pay://, which makes the company the maintainer of a real compatibility and normalization surface rather than only a single checkout page
    • The README also lists a broad supported-asset surface across Bitcoin-family chains, Monero, XRP, Ethereum, Solana, Polygon, Avalanche, and several stablecoins, showing that supported-payment coverage is an operator decision inside one named stack
    • The TypeScript SDK README documents webhook_url, redirect_url, shared-secret verification, and merchant metadata, which means post-payment handoff and callback truth are part of the company-run shell rather than just protocol-neutral address generation
    • The simple-wallet README says the wallet client is compatible with Anypay invoice URLs, reinforcing that the public invoice endpoint and payment-option retrieval flow are part of the live dependency merchants and wallets inherit
    • The web3-checkout README documents an embeddable widget loaded from Anypay infrastructure and keyed by invoice ID with load and payment callbacks, which is a strong sign that checkout UX, callback semantics, and invoice lifecycle sit inside one operator boundary
    • The core repository license block identifies Anypay Inc. as the copyright holder, which is the cleanest primary-source anchor that the relevant control surface is a named company rather than a loose protocol commons
  • Whitepaper: No classic company whitepaper is the point here. The clearest primary materials are the core server README, the TypeScript SDK README, and the adjacent wallet and checkout-widget READMEs already captured in ../whitepapers/anypay-primary-sources-2026-05-02.md.
  • Sources:

Internal linkages

Product / company boundary

  • anypay is the product-layer note for the multi-format payment-request, invoice, redirect, callback, and widget surface developers integrate with.
  • This company note is the operator boundary: Anypay Inc. decides the supported protocol set, branded invoice and widget path, chain-and-token coverage, redirect and webhook semantics, and the official packaging of the server-plus-SDK stack.
  • That split matters because the inherited dependency is not only non-custodial checkout middleware; it is also the named company that defines which payment flows are normalized well and how payment completion is surfaced back to merchant software.

Control surface

  • Practical authority sits in supported payment-request formats, official chain and asset coverage, invoice-URL and widget behavior, webhook-secret and redirect semantics, merchant metadata handling, and the default hosted-versus-self-hosted path Anypay makes easiest.

  • The sticky dependency is not custody of funds. It is workflow control: once a merchant hardens around Anypay invoice IDs, callbacks, redirects, and the official widget or SDK path, the company becomes part of the checkout truth boundary.

  • Treat Anypay as an operator boundary around payment-request normalization and merchant handoff workflow, not just as a generic peer-to-peer payments slogan.

  • Last reviewed: 2026-08-10 UTC

Graph View

Backlinks