Glossary
Account servicing entity (ASE)
An entity that provides and maintains a payment account for a payer and/or payee. An ASE is a regulated entity within the country or countries it operates. Examples include digital wallets, banks, and mobile money providers. Non-regulated entities should not use Rafiki in production environments due to the potential legal and compliance risks involved.
Auth service
A reference implementation of an Open Payments authorization server in Rafiki. The auth service manages grant authorization and authentication, allowing clients (e.g., third-party applications) to create payments and quotes. It issues access tokens and validates client access rights through communication with the resource server.
Authorization server
A server that grants delegated authorization and privileges, via GNAP, to a particular instance of client software in the form of access tokens, allowing the client to call the Open Payments APIs.
We’ve provided an opinionated version of a GNAP authorization server via the auth service, meaning that we’ve made certain decisions regarding the implementation and configuration of the server that may limit customization but ensure consistency and adherence to preferred practices.
Backend service
The core service in Rafiki responsible for managing business logic and external communication. The backend service exposes Open Payments API endpoints for account management, operates an Interledger connector for STREAM packet exchange, and provides a GraphQL Backend Admin API for managing accounts and settings.
Client
An application or service, such as a mobile or web app, that interacts with the authorization server to obtain grants and access tokens. Clients use tokens to access resource servers and perform actions, such as retriving transaction history and setting up payments, on behalf of a user or system.
Frontend service
An optional internal interface in Rafiki, known as the Rafiki Admin, used to manage your Rafiki instance. The frontend service communicates with the Backend Admin API through a Remix web app, facilitating administrative tasks within the Rafiki environment.
Grant Negotiation and Authorization Protocol (GNAP)
The Grant Negotiation Authorization Protocol (GNAP) defines a mechanism for delegating authorization to a piece of software (client), and conveying the results and artifacts of that delegation to the software. This delegation can include access to a set of APIs as well as subject information passed directly to the software. For more information, refer to the GNAP specification.
Grant
A delegation of authorization from a resource owner to a client, allowing the client to access protected resources or perform actions on the owner’s behalf. In Rafiki, this process is managed by the authorization server, which issues grants as access tokens. These grants permit clients to interact with Open Payments APIs to, for example, create payments and retrieve account information, based on the permissions granted by the resource owner.
Identity provider (IdP)
A system or service that stores and manages user identity information, authentication, and consent. Due to Rafiki’s implementation of the Open Payments standard, Rafiki requires integration with an IdP to support interactive Open Payments grants.
Incoming payment
An object created by the recipient’s ASE, on their resource server, that represents a payment being received. The object contains information about the incoming payment, such as the amount, currency, receiver’s wallet address, and payment status. It is used to track and manage payments that are expected to or have been received.
Interledger Protocol (ILP)
An open protocol stack designed to facilitate the transfer of value across different currencies, platforms, and payment networks. Rafiki is a reference implementation of the Interledger stack, allowing you to join the Interledger network and quickly enable Interledger functionality on your users’ accounts. For more information, refer to the Interledger specification.
ILP packet
A unit of data that carries payment information through the Interledger network. A single payment can be broken into smaller packets of value which are then routed across the network.
Open Payments
An API standard and a set of APIs that allows clients to securely retrieve account information and initiate payments from your customers’ accounts with their consent. By adhering to this standard, Rafiki enables integration with external applications and supports the secure and uniform management of payments, quotes, and account data through the Open Payments APIs. For more information, visit the Open Payments documentation.
Outgoing payment
An object created by the sender’s ASE, on their resource server, that represents a payment being sent. This object contains information about the outgoing payment, such as the amount, currency, receiver’s wallet address, and payment status.
Payment pointer
A type of wallet address that serves as an SPSP endpoint to facilitate sending and receiving ILP packets. Payment pointers can be written out using the $ shorthand (e.g., $wallet.example.com/alice) or as a URL (e.g., https://wallet.example.com/alice).
Peer
A counterparty with whom you transact with over the Interledger network. Your Rafiki instance will hold liquidity accounts for each of your peers.
Quote
An object created by the sender’s ASE, on their resource server, that represents the total cost for the sender to send a payment. When a quote is created, it serves as a commitment from the sender’s ASE to deliver the amount to the recipient’s ASE and is only valid for a limited time.
Resource server
A server that hosts and manages access to protected Open Payments resources for incoming payments, quotes, and outgoing payments.
Rafiki’s backend service runs an Open Payments resource server.
Simple Payment Setup Protocol (SPSP)
An Interledger application layer protocol for exchanging payment information between two counterparties to facilitate direct payments over Interledger. The information is then used to set up a STREAM connection. You can read more about SPSP in its specification.
Streaming Transport for the Real-Time Exchange of Assets and Messages (STREAM)
An Interledger transport layer protocol for sending and receiving authenticated ILP packets between peers and determining the path exchange rate. See the STREAM specification for more information.
Wallet address
A secure, unique URL that identifies an Open Payments-enabled account. It acts as an entry point to the Open Payments APIs, facilitating interactions like sending and receiving payments.
A wallet address is publicly shareable and used to interact with the underlying payment account without compromising its security. Wallet address URLs are treated as case-insensitive, meaning that both lowercase and uppercase variations of the same address will be recognized as identical.