Implementing Open Payments

Summary

Implementing Open Payments means standing up the servers that make a financial institution’s accounts Open Payments-enabled. This page is the entry point for engineers at banks, digital wallet providers, and mobile money operators who are building that server stack.

This page is the starting point for account servicing entity (ASE) implementors.

What ASEs build

To make accounts Open Payments-enabled, ASEs operate three servers and integrate with an identity provider:

• A wallet address server that returns public information about each Open Payments-enabled account.
• A resource server that hosts the incoming-payment, quote, and outgoing-payment APIs.
• An authorization server that processes grant requests, issues access tokens, and coordinates user consent.
• An identity provider integration that authenticates the resource owner and collects explicit consent for outgoing-payment grants.

ASEs are also responsible for settlement. Open Payments only carries the payment instruction; actual movement of funds happens between ASEs over a shared payment rail.

What to read

ASEs should refer to the For ASEs section for server-side details. This section is organized as follows:

For ASEs overview What an ASE must build, how this guide relates to the rest of the docs, and where Rafiki fits in.

Wallet address architecture URL constraints, the response contract, multi-currency patterns, and address-to-account mapping policy.

Resource server What the resource server must do for each resource type and how it hands off to settlement.

Authorization server GNAP processing, interactive consent orchestration, and token lifecycle management.

Identity provider integration What the IdP must display, what the auth server passes to it, and how decisions flow back.

Security Signature validation, client key resolution, and interaction hash generation from the server side.

The rest of the docs

The Developer Concepts pages (under Overview → Concepts and Identity and access management) describe what client developers need to know to call the APIs. ASEs are welcome to read them. They describe the same protocol from the other side, but they are not the authoritative source for ASE implementation requirements. The For ASEs section is.

Reference implementation

Rafiki is an open-source implementation of an Open Payments-compatible server stack. The ASE implementation guide describes the standard- and protocol-level requirements; Rafiki’s documentation describes one specific implementation.