​
What you’ll build

The Multi-currency Payment APIs (v2) let you collect (payin) and disburse (payout) funds across many currencies and local payment rails — bank transfers, virtual accounts, mobile money, e-wallets, and QR schemes across APAC, Africa, and Latin America. Funds settle into per-currency float accounts with automatic reconciliation.
The core design principle: methods and their required fields are dynamic. Always discover the available methods and their input schema at runtime rather than hard-coding them, because coverage and requirements vary by country and currency.

​
Prerequisites

  • Merchant account and app-id / secret-key.
  • Sandbox https://api.cleverhub.co; production https://api-merchant.helloclever.co.
  • A webhook endpoint (TLS 1.2, public, commercial cert).
  • Base paths: payins POST /v2/payins, payouts POST /v2/payouts.
Set gst: true only for AU merchants transacting in AUD. For every other currency, set gst: false.

​
Payins — collecting money

1

Get payin methods

Retrieve the list of supported methods for your account / region.
2

Get payin required fields

For the chosen method, fetch its specific required input fields.
3

Create the payin

POST /v2/payins with the method name plus the required fields from the previous step.
4

Simulate (sandbox only)

Call Payin Request Simulation to drive the transaction to completion for testing.
You only need steps 1–2 once per method; reuse the method and field shape afterward.

​
Method-specific behaviour

Some methods return a pay_code to your webhook after a short delay, containing the details your customer uses to complete payment.
Returns bank_name, transfer_id, branch_code, branch_name, account_number, account_name, account_type, transfer_name, expired_timestamp.
Several methods require you to pick from a supported-provider list (bank codes, e-wallets, etc.) before submitting — e.g. sa_eft_zar, my_bank_fpx_myr, th_qrpay_thb, bw_bank_bwp, and br_pix_brl (which uses crypto_ticker + crypto_wallet_address for crypto settlement). Fetch the current provider list for the method before creating the payin.

​
After creation

  • Get payin requests in a period and Get payin details for reconciliation.
  • Refund payin and Cancel payin for post-payment actions.
  • Your webhook fires when status changes to received or return_received.

​
Payouts — sending money

1

Get payout methods

Retrieve supported outbound methods.
2

Get payout required fields

Fetch the required fields for the chosen method.
3

Create the payout

POST /v2/payouts — initialise with the required fields.
Steps 1–2 are one-time per method.

​
Payout statuses

​
Provider lists and helpers

Many payout methods require selecting a bank/e-wallet from a supported list before submitting, including vn_bank_vnd, ph_bank_php, ng_bank_ngn, sa_bank_zar, ke_bank_kes, ke_mobile_money_kes, gh_mobile_money_ghs, cm_mobile_money_xaf, ci_mobile_money_xof, my_bank_myr, the my_ewallet_*_myr family (touchngo, finexus, boost, bigpay, shopeepay, gxbank, merchantrade), br_bank_brl, th_bank_thb, bw_bank_bwp, and ph_qrph_php. Helpers:
  • vn_bank_vnd — use Get Branch Codes when a branch code is required.
  • kr_bank_krw — use the Required Field API to get the current list of supported banks.
  • VND Bank Lookup — a dedicated lookup (e.g. via QR content) is available for Vietnamese accounts.

​
After creation

  • Get payout requests in a period and Get payout details for reconciliation.
  • Payout Simulation (sandbox) to test the flow.
  • Cancel a Scheduled Payout for payouts set to run in the future.

​
Supporting resources

  • Balance (Get balance detail / history) — check per-currency float balances before disbursing.
  • Customer and Contact endpoints — store payer/payee identities and reuse them across transactions.
Payout funds are sourced from your per-currency float balance, made up of accumulated payins and top-ups. Ensure the relevant currency float is funded before initiating a payout.

​
Webhook hygiene

Provide webhook_notification.endpoint_url and authorization_header on create calls. Return 200 OK to every delivery and handle duplicates idempotently; non-200 responses are retried 3× at 15-minute intervals. Use a distinct authorization_header per request.