Overview

Handling payments is a crucial part of many online applications. Whether it’s an eCommerce site selling products, a fundraising platform accepting donations, a streaming service charging for content, or a subscription service with monthly fees, digital payments are central to their operations. Many application developers rely on third-party payment gateways to handle these transactions, which can introduce additional expenses and limit control over the user experience.

Open Payments is an open RESTful API and an API standard that enables clients to interface with Open Payments-enabled accounts. In this context, a client is an application, such as a mobile or web app, that consumes one or more Open Payments 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.

Benefits of Open Payments

When an ASE implements Open Payments, their customers’ financial accounts become Open Payments-enabled. Clients can then call the Open Payments APIs to view an Open Payments-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 without the need for custom integrations with each ASE. Users with Open Payments-enabled accounts can use the app to send funds to another Open Payments-enabled account, regardless of whether the recipient uses the same ASE. This app should be able to connect to any ASE that implements the Open Payments standard without the need for custom integrations.

The Open Payments standard simplifies integration by offering a single access point to various financial accounts, whether they are bank accounts, digital wallets, or mobile money accounts. This approach eliminates the need for multiple custom integrations, similar to how email standards facilitate seamless communication across different email providers.

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

User control and security

With Open Payments, users remain in full control of their financial transactions. When an application uses Open Payments, it securely and cryptographically shares important information about itself with the financial instituion it interacts with. This verification ensures that the account provider knows the application is legitimate when making a payment request on your behalf. Importantly, any withdrawal of money from your account requires your explicit consent, giving you granular control over permissions and transaction limits.

Payments

Open Payments does not execute payments or touch funds in any way. Instead, the APIs allow 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 Open Payments-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 Open Payments-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 Open Payments-enabled account is identified by one or more URLs. These URLs not only identify the account, but are also Open Payments service endpoints that provide the entry point for the API. These URLs are called wallet addresses.

Wallet addresses in Open Payments are designed to be user-friendly and publicly shareable. They function like email addresses, allowing for straightforward and secure interactions with accounts across various financial institutions without exposing sensitive data.

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 APIs. All requests require signatures, which protect the integrity of the requests. Signatures are generated according to the HTTP Signatures specification.

GNAP allows account holders to have 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 aims 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. Open Payments allows for scenarios where clients can dynamically register and engage with the APIs 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.

Open Payments 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

Open Payments aims to simplify and democratize payments by providing a standardized, easy-to-integrate solution. This reduces development effort and enhances financial inclusion by making payment solutions more affordable and accessible to all.

Use cases

Open Payments facilitates various use cases including:

Peer-to-peer payments

A peer-to-peer payment is a type of payment made directly from one person to another via a linked funding source. When ASEs implement the Open Payments standard, applications can call the Open Payments APIs to facilitate peer-to-peer payments. Having a standard means app developers can avoid building custom integrations for each ASE. Plus, app users can hold funding accounts with different Open Payments-enabled ASEs and even use different Open Payments-enabled applications to make peer-to-peer payments.

A peer-to-peer payment can be one-time or recurring. For more information on building an Open Payments client that supports either type, refer to the one-time payment and recurring payments guides.

E-commerce platforms

Suppose a merchant accepts Open Payments as a payment method. Their customers can then pay using their wallet address instead of entering a credit card number and other personal details on the merchant’s site. Open Payments allows an ASE’s account holders to use their wallet addresses for one-time and recurring purchases, such as subscriptions. Refer to the following resources for more details:

• One-time payment guide
• Recurring payments guide

• E-commerce example using the Open Payments SDK

Buy Now and Pay Later (BNPL)

Buy Now and Pay Later (BNPL) plans allow customers to pay for high-priced purchases over time. A customer is relieved from making a large payment at once by splitting up payments at scheduled intervals. Developers can build Open Payments applications that support BNPL plans through recurring payments. For more details, refer to the recurring payments guide.

Web Monetization

The Web Monetization API allows website visitors to pay an amount they choose to a participating website with little to no interaction using Open Payments as the payment method. The site and the site visitor must have an Open Payments-enabled wallet address to receive and send payments.