Rafiki Updates - February 2026

Hello everyone!

February welcomes us with the first Rafiki release of the year: v2.3.0-beta. This version brings us an Open Payments feature, as well as improvements for integrators.

Key highlights

Grant Spent Amounts

To simplify how Open Payments clients track their grant spending, the new Grant Spent Amounts feature allows for direct querying of grant usage. By calling GET /outgoing-payment-grant with a valid GNAP access token belonging to an approved outgoing payment grant, clients can instantly retrieve the spent totals:

GET /outgoing-payment-grant HTTP/1.1
Authorization: GNAP 80UPRY5NM33OMUKMKSKU

{
  "spentReceiveAmount": {
    "value": "2500",
    "assetCode": "USD",
    "assetScale": 2
  },
  "spentDebitAmount": {
    "value": "2600",
    "assetCode": "USD",
    "assetScale": 2
  }
}

Before, when an Open Payments client application wanted to show to their users how much balance a user has left within their approved grant request (or how many funds have already been debited from their account in the form of outgoing payments), they would need to do the accounting themselves. Now, they can do it through this reliable server-side request.

Support for configuring multiple routes per peer

Previously, whenever an integrator created or updated a peer in Rafiki, they could only provide a single static ILP address of the peer, effectively requiring the destination address of any routed packet to match the peer’s address prefix exactly. Now, integrators can also provide a routes field in the backend Admin API createPeer and updatePeer requests: a list of ILP addresses which determine how ILP packets are routed, even if the destination address does not match the peer's ILP addres prefix. This essentially allows fine-tuning ILP's multi-hop payment configuration.

completeIncomingPayment backend Admin API

This new backend Admin API mutation allows integrators to mark local incoming payments or remote incoming payments (hosted on other Open Payments resource servers) as completed through a single API request. Before, this functionality was only possible through the Open Payments API.

Multi-tenancy improvement

Another addition to the backend Admin API is the introduction of the tenant field resolver for tenanted resources. Instead of just being able to get the tenantId field when querying tenanted resources, you can also directly resolve the full tenant object within the same request.

Next up

Other than continuing with the encrypted data exchange feature, we have started the Rafiki implementation for the Open Payments directed identity feature. This feature will allow Open Payment clients to get non-interactive grants (e.g. creating incoming payments) by presenting a JWK instead of their wallet address. You can see how this behaviour will be supported by seeing the new v1.3.0 release of the Open Payments API specifications.

See you next month!