Open Payments is trying to standardize how applications initiate and coordinate payments against user accounts without hard-coding one payment rail, wallet vendor, or banking integration. The official materials repeatedly frame it as an API standard that can sit above banks, digital wallets, and mobile money providers.
The core decomposition is wallet address server / resource server / authorization server. That split is the main reason the project belongs in the corpus: public account discovery, account operations, and delegated permission grants are treated as separate protocol surfaces.
Wallet addresses are not just prettier account names. The Interledger overview and developer docs describe them as public URL aliases that let applications discover where an account provider lives and how to request permission, while the provider keeps the underlying financial account and customer data private.
The developer docs are especially useful because they make the settlement boundary explicit: Open Payments does not execute payments or touch funds. Instead, it standardizes payment instructions and account permissions, while the sending and receiving account-servicing entities settle outside the protocol over whatever common rail they share.
GNAP-based authorization is a second crucial control surface. The docs say clients need grants before issuing payment instructions, and those grants can carry fine-grained rights, limits, time bounds, and recurring-payment permissions.
The project also positions itself against incumbent open-banking ecosystems. The docs argue that Open Payments should allow dynamic registration and direct client-to-provider interaction without forcing every merchant or app through aggregator-style pre-registration chokepoints.
The public repos reinforce that this is not just a concept page. The main repository publishes the docs corpus, while the specifications repository publishes versioned OpenAPI specs for the wallet-address, resource-server, and authorization-server layers.
Specific source signals worth retaining
The Interledger Foundation overview is the best concise source for the user-facing wallet-address framing and for the provider-to-provider payment-obligation model after consent.
The openpayments.dev getting-started page is the best source for the deeper architecture: account-servicing entities, grants, HTTP-signature-based request integrity, GNAP authorization, and the explicit claim that Open Payments separates payment instructions from settlement execution.
The main GitHub README is the clearest compact source for the three-subsystem architecture and the intended interoperability across banks, digital wallets, and mobile money providers.
The specifications README is the best source for the fact that the protocol is concretely expressed as maintained OpenAPI specs rather than only narrative docs.
Why this entry belongs in the corpus
It gives the payments cluster a cleaner comparison point for wallet-address discovery, grant negotiation, and provider-routed payment initiation than rail-specific crypto payment standards alone.
It helps separate public account discovery, delegated authorization, payment instruction creation, and actual settlement, which are often flattened together under generic payments or open banking labels.
The durable insight is that a large part of payment interoperability sits above settlement rails: in who publishes account endpoints, who grants scoped access, how applications authenticate themselves, and which provider-to-provider obligations exist once a user consents.