Implementing Open Payments

Summary

Implementing Open Payments means standing up the servers that make a financial service provider’s accounts Open Payments-enabled. This page is the entry point for engineers at banks, digital wallets, mobile payment systems, and other providers who are building that server stack.

This page is the starting point for financial service provider (FSP) implementors.

What FSPs build

To make accounts Open Payments-enabled, FSPs 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 interactive grants.

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

What to read

FSPs should refer to the For FSPs pages for server-side details. The pages are organized as follows:

FSP overviewWhat an FSP must build, how these pages relate to the rest of the docs, and where Rafiki fits in.

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

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

Authorization serverGNAP processing, interactive consent orchestration, and token lifecycle management.

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

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

The rest of the docs

The Developer Concepts pages (under For Developers → Concepts) describe what client developers need to know to call the APIs. FSPs are welcome to read them. They describe the same protocol from the other side, but they are not the authoritative source for FSP implementation requirements.

Reference implementation

Rafiki is an open-source implementation of an Open Payments-compatible server stack. The For FSPs pages describe the standard and protocol-level requirements. Rafiki’s documentation describes one specific implementation.