Skip to content

dharmikumbhani/payto-spec

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

16 Commits
 
 
 
 
 
 
 
 
 
 

Repository files navigation

PayTo: An Open Standard for Payment Discovery for Websites

PayTo - An Open Standard for Payment Discovery for Websites

PayTo gives every website a standard, origin-scoped place to publish how to get paid. Tools and wallets fetch one JSON file, show safe payment options, and (if signed) enable trusted autofill—no scraping, no copy-paste, fewer mistakes.

Read the Spec Here - docs/payto-spec.md

Why this exists

Today, "send money to a website" is messy: crypto addresses live in docs or tweets, payment links change, and copy-paste is easy to phish. Wallets don't have a trustworthy, origin-scoped place to learn where funds should go or what the site wants to ultimately receive. There's no predictable, machine-readable source of truth.

What this spec solves

/.well-known/payto is a tiny JSON file at a predictable URL on your domain. It lists how you can receive funds (Bitcoin, EVM chains, Solana, Lightning), what assets you accept, and what you prefer to settle in (including an optional target final amount). With optional signatures (JWKS) and address proofs, wallets can fetch it, verify it, and safely auto-fill send details—no copy-paste, fewer mistakes, less phishing.

Use cases

Universal tipping — Browser extensions can tip any site the same way

Independent creator support — Blogs and newsletters get direct payments without platform fees

Machine payments — AI agents and crawlers can compensate content creators automatically

Standardized donations — Companies and DAOs publish payment preferences once, all clients discover them

What PayTo does not do

PayTo is a discovery layer, not a payment processor. It doesn't handle checkout flows, set prices, guarantee payments, or replace existing subscription systems.

How is this different from x402?

PayTo is a tiny, origin-scoped file at /.well-known/payto that tells wallets how this website accepts funds (e.g., BTC, EVM, Solana, Lightning). It's out-of-band discovery: tools can read it anytime without changing your app.

x402 is an in-band HTTP flow for pay-per-request. A server replies with 402 Payment Required, the client pays, then the server returns the resource. It's a runtime payment gate for specific endpoints.

Can they coexist? Yes, PayTo publishes your receiving details in one predictable place, while x402 gates specific API/content endpoints with on-the-spot payment requirements.


Example: donations without copy-pasted addresses

Today, many sites paste wallet addresses into the UI. That's brittle and easy to spoof. With PayTo, you can simply say:

"Send donations to freeross.com."

A wallet or extension can then:

  1. Fetch https://freeross.com/.well-known/payto
  2. Display the site's listed methods (e.g., BTC, USDC on Base, Lightning)
  3. Let the user pick and confirm, then send—no copy-paste, fewer mistakes

(Optional) If the PayTo file is signed, wallets can show a "verified" badge; if not, they still display methods and ask for confirmation.

About

No description, website, or topics provided.

Resources

License

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published