Open Payments is an HTTP-based API, and multi-party protocol using the API, that can be implemented by any account servicing payment service provider (ASPSP) to enable “programmable money” for their customer’s accounts.
Taking inspiration from Open Banking and the growing popularity of account-to-account (A2A) payments, the Open Payments APIs expose mechanisms for account holders (and third-parties with delegated authority) to accept and initiate payments to and from an account, all via APIs.
The goal of Open Payments is to define a standard API and protocol for access to an account so that applications can connect to their user's financial accounts and integrate payments into their feature set.
By defining an open standard it should be possible for an application to connect to any ASPSP that implements the standard without requiring custom integrations or aggregators.
Using fine grained access grants, account holders can have very specific control over the permissions they grant to applications that connect to their account. This enables powerful use cases such as third-party payment initiation and delegated authorisation without compromising the security of the underlying account.
Every account that is accessible via Open Payments APIs is identified by one or more URLs. These URLs not only identify the account but also provide the entry point for the API.
URLs that are Open Payments service endpoints are called Payment Pointers and are described in more detail later in this guide.
The ability to execute account-to-account transfers between account providers that implement the Open Payments API is predicated on the availability of a common payment rail between the providers that supports real-time payments.
To accommodate this it is presumed that account providers are connected to one another using the Interledger protocol and that payments will be executed via Interledger. Interledger provides an interoperability layer over existing payment rails and abstracts away the differences between these making it possible to define a single protocol (Open Payments) for the application layer that can ignore differences in how the payments will be cleared and settled.
The Grant Negotiation and Authorization Protocol (GNAP) is a protocol developed at the IETF to succeed OAuth 2.0.
Open Payments leverages GNAP to define a standard mechanism for requesting and granting access tokens for the Open Payments APIs. More details on GNAP and how it is used in the Open Payments APIs is provided in the Security section of this guide.
Open Payments attempts to improve upon existing Open Banking standards (as defined in the UK, EU and other jurisdictions) in two fundamental ways.
First, it allows for scenarios where clients dynamically register and engage with the APIs without needing to pre-register with the account provider. This allows for a truly distributed and federated payment ecosystem with global reach and no dependence on any particular underlying account type or settlement system. Existing Open Banking ecosystems are dominated by aggregators and intermediaries making it impossible for an independent 3rd-party such as a small merchant, to use payment initiation APIs directly against their customer’s accounts.
Second, Open Payments assumes the presence of a universal payment rail between all accounts (global account-to-account payments), based on the Interledger protocol, where all counter-party accounts are also addressable as URLs, making Open Payments a borderless, global platform that fits naturally into the Internet and Web economies.
The goal of Open Payments is to define a standard that is adopted by all account servicing payment service providers (banks, digital wallets, mobile money providers etc.), creating an application layer for the Internet of Value. This would allow applications to integrate payments directly into their products without requiring users to create new accounts for every application.
Updated 9 months ago