Skip to content
GitHub

Overview

Open Payments is an open RESTful API and API standard that enables clients to interface with Open Payments-enabled accounts. In the context of Open Payments (OP), a client is an application, such as a mobile or web app, that consumes one or more OP resources, typically requiring access privileges from one or several authorization servers.

The Open Payments standard is meant to be implemented by account servicing entities (ASEs). ASEs provide and maintain payment accounts for payers and payees, and are regulated entities within the countries they operate. Examples of ASEs include banks, digital wallet providers, and mobile money providers.

When an ASE implements Open Payments, their customers’ financial accounts become OP-enabled. Clients can then call the Open Payments API to view an OP-enabled account’s transaction history and certain account details, as well as issue instructions for receiving payments into and sending payments from the account.

For example, an application developer can build payments functionality into their app such that a user with an OP-enabled account can use the app to send funds to another OP-enabled account regardless of whether the recipient uses the same ASE. The app should be able to connect to any ASE that implements the Open Payments standard without the need for custom integrations.

Refer to the Open Payments concepts and Open Payments flow pages for additional details.

Payments

Open Payments does not execute payments or touch funds in any way. Instead, the API allows clients to issue payment instructions to ASEs.

For example, a client can instruct an ASE to send a payment of $20.00 USD from its customer’s account to another OP-enabled account at a different ASE. The sending ASE is responsible for executing and settling the payment with the receiving ASE outside of Open Payments. The ability to execute payments between OP-enabled ASEs is predicated on the availability of a common payment rail between the ASEs.

By separating payment instructions from execution/settlement, client developers can include payment functionality within their feature sets without, for example, also registering as a licensed money transfer business.

Open Payments account identification

Every OP-enabled account is identified by one or more URLs. These URLs not only identify the account, but are also OP service endpoints that provide the entry point for the API. These URLs are called wallet addresses.

Grant negotiation and authorization

Clients must receive grants before issuing payment instructions. Grants give clients the authorization, via access tokens, to perform one or more operations. Grants represent the rights that are given to the client, such as the right to create an incoming payment request.

Open Payments leverages the Grant Negotiation and Authorization Protocol (GNAP) to define a standard mechanism for clients to request and receive the grants necessary to use the Open Payments API. All requests require signatures, which protect the integrity of the requests. Signatures are generated according to the HTTP Signatures specification.

GNAP makes it possible to give account holders specific and fine-grained control over the permissions they grant to the clients that connect to their accounts, including control over the amounts of transactions with time-based and velocity-based limits. This enables powerful use cases such as third-party payment initiation and delegated authorization without compromising the security of the underlying financial accounts and payment instruments.

Review the Grant negotiation and authorization page for more information.

Relation to Open Banking

Open Payments attempts to improve upon existing Open Banking standards as defined in the UK, EU, and other jurisdictions.

Existing Open Banking ecosystems are dominated by aggregators and intermediaries, making it impossible for independent third-parties, such as small merchants, to use payment initiation APIs directly against their customers’ payment accounts. OP allows for scenarios where clients can dynamically register and engage with the API without needing to pre-register with the ASE. 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.

OP is also a significantly simpler standard with a small number of resource types and a more secure and powerful authorization protocol.

Goals

The goal of Open Payments is to define a standard that’s adopted by all ASEs. The standard doesn’t rely on any singular payment method, currency, or programming language, encouraging interoperability between ASEs and other parties.

When an ASE adopts the Open Payments standard, clients (applications and other parties) will know how to interact with the ASE and can integrate payments directly into their products without requiring:

  • End-users to create a new payment account for every application and/or website they use
  • Developers to build clients in any one programming language
  • ASEs and clients to create and deploy custom integrations to communicate with one another