country_code +
currency_code). Instead of sending the full recipient details on every payout,
you create the beneficiary once and then reference its beneficiary_id.
Beneficiaries belong to payouts. Every endpoint here requires the same JWT from
/api/v1/user/login that sendPayoutRequest does, and an account without
the payout product cannot reach them. This is the opposite of payins, which take no JWT
at all.Why use them
- Validate early. Per-country requirements (account formats, KYC fields) are checked when you create the beneficiary, not at payout time.
- Smaller payout calls. A payout in beneficiary mode only carries the amount.
- Stable contract. The fields a corridor requires are defined by PontisGlobe and don’t change if we route through a different underlying provider.
Lifecycle
- Create —
addBeneficiarywith the corridor + per-countryrecipient_details. We validate the fields and return abeneficiary_id. - Use — pass that
beneficiary_idtosendPayoutRequestin beneficiary mode. - Manage — fetch, list, update or archive them.
Corridor requirements
Every corridor requiresrecipient_details.name. The remaining fields fall into
a few groups depending on the destination:
Field-level tables (types, formats, exact required flags) are returned by the validation errors on
addBeneficiary and shown in the dashboard’s add-beneficiary
form. Corridors marked “Mobile money” require a payment_network (e.g. VODACOM, MTN,
AIRTEL).Security
- Beneficiaries are scoped to your account. A
beneficiary_idfrom one account is never usable by another; lookups for an id you don’t own return404. - Read responses mask sensitive values (e.g. last 4 of an account number).
- Sandbox and live beneficiaries are isolated — a sandbox beneficiary cannot be used for a live payout.