Getting Started
Account Servicing Entities provide and maintain payment accounts. In order to make these accounts Interledger-enabled via Rafiki, they need to provide the following endpoints and services:
Furthermore, each payment account managed by the Account Servicing Entity needs to be issued at least one wallet address in order to be serviced by Rafiki and send or receive Interledger payments.
Exchange Rates
Every Interledger payment is preceded by a rate probe that estimates the costs for transferring value from A to B over the network (= network fee). For the rate probe to be successful, Rafiki needs to be provided with the current exchange rate by the Account Servicing Entity. The Account Servicing Entity needs to expose an endpoint that accepts a GET
requests and responds as follows.
Response Body
Variable Name | Type | Description |
---|---|---|
base | String | asset code represented as ISO 4217 currency code, e.g. USD |
rates | Object | Object containing <asset_code : exchange_rate> pairs, e.g. {EUR: 0.8930} |
rates.<asset_code> | Number | exchange rate given base and <asset_code> |
The response status code for a successful request is a 200
. The mock-account-servicing-entity
includes a minimalistic example.
The backend
package requires an environment variable called EXCHANGE_RATES_URL
which MUST specify the URL of this endpoint. An OpenAPI specification of that endpoint can be found here.
Rate Probe Quotes and Fees
The Account Servicing Entity may charge fees on top of the estimated network fee for facilitating the transfer. They can specify fixed and variable fees per asset using the Admin API or UI. How they structure those fees is completely up to the Account Servicing Entity.
Sending fees can be set on a given asset using Admin UI or the setFee
graphql mutation if desired:
Mutation:
Query Variables:
Example Successful Response
Webhook Events Listener
Rafiki itself does not hold any balances but needs to be funded for outgoing transfers and money needs to be withdrawn for incoming transfers. In order to notify the Account Servicing Entity about those transfer events, they need to expose a webhook endpoint that listens for these events and reacts accordingly.
The endpoint accepts a POST
request with
Request Body
Variable Name | Type | Description |
---|---|---|
id | String | event id |
type | Enum: EventType | |
data | Object | any additional data |
EventType
Value | Description |
---|---|
incoming_payment.created | Incoming payment has been created. |
incoming_payment.completed | Incoming payment is complete and doesn’t accept any incoming funds anymore. |
incoming_payment.expired | Incoming payment is expired and doesn’t accept any incoming funds anymore. |
outgoing_payment.created | Outgoing payment was created. |
outgoing_payment.completed | Outgoing payment is complete. |
outgoing_payment.failed | Outgoing payment failed. |
wallet_address.not_found | A requested wallet address was not found |
wallet_address.web_monetization | Web Monetization payments received via STREAM. |
asset.liquidity_low | Asset liquidity has dropped below defined threshold. |
peer.liquidity_low | Peer liquidity has dropped below defined threshold. |
The Account Servicing Entity’s expected behavior when observing these webhook events is detailed in the Event Handlers documentation.
The backend
package requires an environment variable called WEBHOOK_URL
which MUST specify this endpoint. An OpenAPI specification of that endpoint can be found here.
Identity Provider
The Rafiki backend
exposes the Open Payments APIs. They are auth-protected using an opinionated version of the Grant Negotiation Authorization Protocol (GNAP). Rafiki comes with a reference implementation of an Open Payments Auth Server—the auth
package.
The Open Payments Auth Server requires integration with an Identity Provider to handle user authentication and consent. For more information on how to integrate an Identity Provider with the reference implementation of the Open Payments Auth Server, see the docs in the auth
package.
Issuing Wallet Addresses
A Wallet Address is a standardized identifier for a payment account. It can be created using the Admin API. Note that at least one asset has to be created prior to creating the wallet address since an assetId
MUST be provided as input variable on wallet address creation.
Create Asset
Query:
Query Variables:
Example Successful Response
Create Wallet Address
Query:
Query Variables:
Example Successful Response
The Account Servicing Entity SHOULD store at least the walletAddress.id
in their internal database to be able to reference the account and wallet address.
Create Wallet Address Key
In order to use the Open Payments APIs, a wallet address needs to be associated with at least one private-public-keypair to be able to sign API request. One or multiple public keys are linked to the wallet address such that third-parties can verify said request signatures. It can be added using the Admin API.
Query:
Query Variables:
Example Successful Response