Payment Pointers are intentionally a narrow identifier and discovery spec. The official site frames them as standardized identifiers for payment accounts, analogous to how email addresses identify mailboxes.
The core mechanism is $host/path resolving to an HTTPS URL, with empty-path pointers defaulting to /.well-known/pay. That is the main reason the entry belongs in the corpus: naming and endpoint discovery are isolated as their own control surface.
The syntax page makes clear that Payment Pointers are a restricted profile rather than arbitrary URLs. They exclude userinfo, ports, query strings, and fragments, and invalid pointers must not be used for resolution.
HTTPS is not incidental. The syntax and flow pages require HTTPS resolution and HTTPS-preserving redirects, which means ordinary web-origin trust and redirect policy become part of the payment-discovery trust model.
The flow page is especially useful because it shows that Payment Pointers stop at discovery: a client resolves the pointer, queries the resulting URL to discover available endpoints, and only then initiates payment behavior through supported protocols.
The Open Payments glossary adds an important distinction: a Payment Pointer may serve as a wallet address when Interledger is used, but not every Open Payments wallet address is necessarily a Payment Pointer. That keeps the lower-bound profile separate from the broader wallet-address layer.
The Open Payments getting-started docs and specifications repo are useful supporting sources because they show how the broader stack adds wallet-address publication, resource-server operations, and GNAP authorization above the narrower Payment Pointer discovery layer.
Specific source signals worth retaining
The homepage is the best compact statement of purpose: Payment Pointers are standardized identifiers for payment accounts and resolve to secure URLs used to discover Open Payments endpoints.
The syntax page is the most analytically important source because it spells out the restricted grammar, the deterministic https:// resolution rule, and the /.well-known/pay fallback.
The flow page is the clearest source for the trust boundary around redirects and the sequence from pointer resolution to endpoint discovery to later payment initiation.
The Open Payments glossary is the best source for the distinction between wallet addresses and payment pointers, which prevents overgeneralizing the pointer format into the whole payment-initiation stack.
Why this entry belongs in the corpus
It gives the payments cluster a lower-bound naming and discovery primitive beneath Open Payments, Interledger SPSP-style setup, and machine-commerce APIs.
It helps separate account aliasing and endpoint publication from authorization, quote creation, payment transport, and settlement.
The durable insight is that a meaningful part of payment interoperability sits in who controls the endpoint a user publishes and how clients resolve and trust that endpoint before any money movement happens.