Skip to main content
Two reads, and by the end you will know exactly which currencies your integration can offer and what a payout to one of them needs.

1. Ask a narrow question

Listing every currency is rarely what you want. Filter by the capability you are about to use.
The response is a plain array, sorted by code:
Two things to take from it:
  1. minorUnits is the number your arithmetic needs. Store it next to every amount you handle. 2 for most currencies, 0 for UGX, 8 for crypto.
  2. The six booleans are independent. A currency you can hold is not necessarily one you can convert. Pick the switch that matches the operation you are about to attempt.

2. Ask what can deliver

Now the other direction: you want to pay someone in Kenyan shillings.
Each route carries the id you will send as routeId, and the exact fields that route needs:
fieldDescriptors is the point of the call. It is a form specification: render those fields, with those labels, those constraints, and those options, and the payment detail you build from them will validate.
An empty array is a valid answer. The currency code is not checked against the currency list, so [] means “nothing delivers there”, not “you asked wrongly”.

3. Populate the country picker

No credentials needed for this one.
Cache it for a day — the response says so with Cache-Control: public, max-age=86400. Use code for every jurisdiction and address.country field you send.

Which endpoint for which job

Next