Payment Pointers

• Name: Payment Pointers
• URL: https://paymentpointers.org/
• Category: payment-account identifier standard / HTTPS discovery primitive / wallet-address lower-bound specification
• Summary: Payment Pointers are just web-native account aliases. They map $host/path to an HTTPS endpoint and stop there. That thinness is the point: they are useful precisely because they do not smuggle in auth, settlement, or wallet logic.
• What it does:
  • Defines a compact payment-account identifier syntax using $ followed by a host and optional path
  • Specifies deterministic resolution from a Payment Pointer to an HTTPS URL, with empty paths defaulting to /.well-known/pay
  • Excludes ports, query strings, fragments, and other general-URL baggage from the identifier surface
  • Requires HTTPS resolution and HTTPS-preserving redirects
  • Lets higher-layer systems resolve a shareable identifier into an account or service endpoint before initiating payment-specific flows
• Key claims:
  • Payment Pointers matter because they isolate naming and endpoint discovery from authorization and settlement instead of bundling everything into one vague payments surface
  • The $-to-https:// mapping means the real trust anchor is ordinary web infrastructure: domain control, TLS termination, and redirect policy
  • The .well-known/pay fallback is the core convention, not a side detail
  • The syntax restrictions keep the format closer to an account alias than to an arbitrary URL
  • Open Payments documentation is useful here because it makes clear that a payment pointer can be a wallet address in Interledger contexts, but not every wallet address is a payment pointer
• Whitepaper: No standalone whitepaper surfaced in this pass. The strongest primary materials were the official Payment Pointers site, syntax and flow pages, and Open Payments documentation collected in ../../whitepapers/payment-pointers-primary-sources-2026-05-15.md.
• Sources:
  • https://paymentpointers.org/
  • https://paymentpointers.org/syntax/
  • https://paymentpointers.org/flow/
  • https://openpayments.dev/resources/glossary/
  • https://openpayments.dev/overview/getting-started/
  • https://github.com/interledger/open-payments-specifications
  • https://raw.githubusercontent.com/interledger/open-payments-specifications/main/README.md

Internal linkages

• Strongest higher-layer note: open-payments
• Lower transport and settlement lineage: interledger
• Naming cousin worth keeping nearby: lnurl

Control surface

• Payment Pointers are thin on purpose, so the leverage sits almost entirely in domain control, HTTPS termination, redirect policy, and who actually operates the resolved pay endpoint.

• That thinness is the useful analytical cut. The standard does not decide auth, balances, or settlement; the operator behind the HTTPS endpoint does.

• When a product tries to smuggle more meaning into the pointer itself, separate the alias from the account, grant, or wallet logic living behind it.

• Last reviewed: 2026-06-16 UTC