Anypay

• Name: Anypay
• URL: https://github.com/anypay/anypay
• Category: non-custodial merchant checkout control plane / multi-format payment-request normalization / invoice and callback infrastructure
• Tags: bitcoin-ecosystem
• Summary: Anypay is checkout plumbing. The useful part is invoice creation, payment-request normalization, redirects, and callbacks with less custody baggage than a typical processor. The any kind of value line is marketing; the product is mostly merchant integration middleware. The named operator boundary around invoice URLs, supported-payment coverage, official widget behavior, and webhook / redirect workflow now lives separately in anypay.
• What it does:
  • Provides developer-facing infrastructure for invoice and payment-request flows aimed at retail, ecommerce, and in-app crypto payments
  • Supports multiple payment-request standards, including JSON Payment Protocol, BIP70, BIP270, and Anypay’s own pay:// format
  • Exposes a TypeScript SDK for creating payment requests to one or more destination addresses across multiple currencies and chains
  • Supports webhook callbacks, redirect flows, merchant metadata, and invoice-driven checkout experiences through SDK and widget surfaces
  • Publishes wallet/testing tooling that can fetch payment options from Anypay invoice URLs and submit compatible payments programmatically
  • Positions itself as non-custodial infrastructure, with payments flowing directly from the payer wallet to the desired destination instead of through Anypay custody
• Key claims:
  • The core README says Anypay was created to help developers build apps that transfer “any kind of value on any open system” and 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 multiple payment protocols — JSON Payment Protocol, BIP70, BIP270, and pay:// — so that different payment-request formats can be normalized behind one system
  • The core README lists native support for Bitcoin, Bitcoin Cash, Bitcoin SV, Dogecoin, Litecoin, Dash, Monero, XRP, Ethereum, Solana, Polygon, and Avalanche, including stablecoin support on several chains
  • The TypeScript SDK README says applications can request payments to multiple addresses in multiple cryptocurrencies and emphasizes that funds are never held by a third party
  • The SDK also documents concrete integration primitives such as webhook_url, redirect_url, shared-secret verification, and merchant metadata, which makes Anypay look like a checkout-control-plane product rather than only a protocol experiment
  • The simple-wallet README says its wallet/client tooling is compatible with the JSON Payment Protocol V2 spec and can retrieve payment options from Anypay invoice URLs before selecting and sending a payment
  • The web3-checkout README documents an embeddable popup widget keyed by Anypay invoice ID with load and payment callbacks, reinforcing that the stack includes real merchant-facing checkout UX rather than only backend libraries
• Whitepaper: No canonical standalone Anypay whitepaper or litepaper surfaced in this pass. The clearest current sources of truth were the official GitHub org’s server, SDK, wallet, and checkout-widget READMEs; see ../whitepapers/anypay-primary-sources-2026-05-02.md.
• Sources:
  • https://github.com/anypay/anypay
  • https://raw.githubusercontent.com/anypay/anypay/main/README.md
  • https://github.com/anypay/anypay-sdk
  • https://raw.githubusercontent.com/anypay/anypay-sdk/master/README.md
  • https://raw.githubusercontent.com/anypay/simple-wallet/master/README.md
  • https://raw.githubusercontent.com/anypay/web3-checkout/main/README.md

Internal linkages

• Company / operator boundary for invoice namespace, hosted widget behavior, chain-and-token support, and callback truth: anypay.
• Best upward reads: btcpay-server and open-payments.

Product / company boundary

• Keep this note on the product surface: multi-format payment-request normalization, invoice creation, non-custodial checkout flow, redirect handling, webhook callbacks, and widget-facing merchant integration behavior.
• Use anypay for the named-operator layer above that product: the company that maintains the official server / SDK / widget stack, defines supported protocol and asset coverage, and becomes part of the hosted payment-completion and callback shell.
• That split matters because how does Anypay normalize a payment request? and who controls the branded workflow surface merchants and wallets rely on? are related but not identical questions.

Control surface

• Power sits in invoice creation, supported payment-request formats, redirect and webhook behavior, merchant metadata handling, and whichever wallet/payment options Anypay chooses to normalize well.

• The product note still matters because the integration surface is real. But once an app depends on Anypay invoice URLs, official widget behavior, and callback semantics, the operator boundary above it matters too.

• The real comparison is not to grand interoperability theories. It is to other merchant stacks that decide how checkout state, payment confirmation, and post-payment handoff are packaged for developers.

• Last reviewed: 2026-08-10 UTC