Open Payments

• Name: Open Payments
• URL: https://interledger.org/open-payments
• Category: payment-initiation standard / wallet-address discovery protocol / grant-based payment authorization infrastructure
• Summary: Open Payments is an account-discovery and grant-negotiation stack, not a settlement rail. The useful part is the split between wallet-address discovery, resource-server account operations, and GNAP-based authorization, because that keeps permissioning, routing, and settlement from collapsing into one vague payments bucket.
• What it does:
  • Defines wallet addresses as public URL aliases that let applications discover where an Open Payments-enabled account lives and how to request access to it
  • Standardizes a three-part architecture consisting of a wallet address server, a resource server, and an authorization server
  • Lets clients request grants before performing actions like viewing transaction history, creating incoming-payment requests, or issuing outgoing payment instructions
  • Uses GNAP-style delegated authorization and signed requests so applications can receive fine-grained, time-bounded, and amount-bounded permissions from account holders
  • Separates payment instruction and account-permission logic from the actual execution and settlement of funds between account-servicing entities
  • Targets interoperability across banks, digital wallet providers, and mobile money providers rather than one cryptocurrency network or one account type
• Key claims:
  • The Interledger Foundation overview says Open Payments should make sending money as easy as sending email and frames wallet addresses as public, shareable, interoperable aliases for accounts rather than as exposed financial credentials.
  • The developer docs are especially important because they say plainly that Open Payments does not execute payments or touch funds. Instead, applications issue instructions to account-servicing entities, and those entities settle with each other outside the protocol over whatever common rail they share.
  • The main architectural split is the core reason to keep this project in the corpus. Public wallet-address discovery, account-resource operations, and GNAP authorization are separate protocol surfaces, which makes it easier to compare Open Payments against machine-payment HTTP standards, wallet-auth systems, and open-banking APIs without collapsing them together.
  • The docs also make the control surface around grants explicit. Clients need authorization before they can act, and account holders can grant fine-grained permissions with time-based and velocity-based limits. That makes Open Payments as much an authorization protocol as a payment protocol.
  • Another durable signal is the project’s claim that it avoids some open-banking chokepoints by supporting more dynamic client interaction and not depending on one aggregator or mandatory pre-registration model for every third-party app.
  • Open Payments belongs in the active corpus because it gives the payments cluster a strong account-discovery and permissioning baseline. If it were filed only as generic fintech API infrastructure, the more reusable mechanism insight — wallet-address publication plus scoped grant negotiation above settlement rails — would be easy to lose.
• Whitepaper: No canonical standalone Open Payments whitepaper surfaced in this pass. The strongest primary materials were the Interledger overview, the developer docs, the main GitHub README, and the OpenAPI specifications repo collected in ../../whitepapers/open-payments-primary-sources-2026-05-13.md.
• Sources:
  • https://interledger.org/open-payments
  • https://openpayments.dev/overview/getting-started/
  • https://github.com/interledger/open-payments
  • https://raw.githubusercontent.com/interledger/open-payments/main/README.md
  • https://github.com/interledger/open-payments-specifications
  • https://raw.githubusercontent.com/interledger/open-payments-specifications/main/README.md

Internal linkages

• Lower-bound naming and endpoint-discovery primitive: payment-pointers
• Grant-negotiation substrate that makes the account / auth-server split legible: gnap
• Paid-request contrast where the reusable authority object is a fulfilled HTTP payment challenge rather than an auth-server grant: x402

Control surface

• Open Payments is basically discover account + negotiate grant + issue instruction. That is the useful cut. It is not the settlement rail.

• The practical leverage sits with the provider that controls wallet-address publishing, authorization-server UX, resource-server policy, payout routing, and compliance gates.

• That is why the note matters: it separates naming, permissioning, and downstream fund movement cleanly enough to compare against wallet-auth systems, paid-request protocols, and open-banking-style APIs without flattening them into one payments bucket.

• Last reviewed: 2026-05-25 UTC