Skip to main content

1. Pay the same people every month

Save each payee once, then each run is one destination call per payee. Onboarding a payee — three calls, done once:
Each payout run — one destination and one transfer per payee:
The name comparison is worth keeping. On routes with account verification, displayName is the name the bank holds — a mismatch means the account number is wrong, or belongs to someone else.

2. One-off payout

A refund to someone you will never pay again does not need a recipient.
Two differences from the saved path:
  • Routing fields are top-level, not inside a fields object. bankCode and accountNumber sit beside routeId.
  • The counterparty profile is on you. The four recipient* fields are what the payout rail requires; the parser will accept the request without them and the provider will not.
Add "saveRecipient": true and Sakawave keeps the recipient for next time — the middle ground between the two paths.

3. Pay inside Sakawave

Two shapes, and the difference catches people out.
Both fail the same way when the target cannot receive:
One code covers every cause — wrong id, inactive, canCredit false, currency mismatch, a wallet given to own_account, or an account that is not yet transferReady. That is deliberate: it stops the endpoint being used to discover which accounts exist. When it happens against an account you own, read the account and check those five things yourself.

4. Rotate a bank account

A payee changes bank. There is no update endpoint, so this is add-then-remove — in that order.
Deleting first would leave the payee unpayable if the new detail turned out to be wrong, and you cannot read the old value back to restore it.
Deleting the default detail promotes another automatically. Add the replacement as the default before removing the old one, or the promotion will pick whichever detail happens to be next.

Offboarding a payee

The recipient and its details are deactivated. Transfers already made keep their masked snapshot of where the money went, so history stays readable. Two caveats: there is no undelete — recreating mints a new id — and a destination already resolved from this recipient stays spendable until it expires.

What you cannot do here

  • Update anything. No PATCH on a recipient or a payment detail, except promoting a default.
  • Read routing values back. maskedIdentifier is final.
  • Reuse a destination. Single use, 24 hours.
  • Search or page recipients. GET /v1/transfer-recipients takes no parameters and returns everything.
  • Pay a customer wallet by own_account. Use the tag.