Individual vs business — which flow am I in?
Our banking partner has two distinct customer types, and they don’t mix. Their onboarding, KYC, collections, and payouts are separate journeys. Pick the one that matches who is sending the money.
| Individual | Business / treasury | |
|---|---|---|
| Who the sender is | Your end-user (e.g. a Pouch app user) | Your own merchant entity |
| You’re moving | Money on behalf of an end-user | Your own funds |
| Customer record | One per end-user — POST /v1/customers with type: individual | Your merchant entity, onboarded with Technest (KYB) |
| Collections (receiving) | The end-user’s own virtual account (GBP/USD/EUR) or CAD Interac | The merchant’s international accounts |
| Payouts (sending) | sender_customer_id = the end-user; funds leave the end-user’s own account | No per-payout sender; funds leave the merchant’s international account (treasury mode) |
| Payout gate (GBP/USD/EUR) | Sender’s own active VBA → else sender_account_not_provisioned | Merchant’s active international account → else no_active_international_account |
| CAD | Interac e-Transfer or EFT — no account gate in either flow | Interac e-Transfer or EFT — no account gate in either flow |
Most remittance integrators (IMTOs, MSBs, EMIs moving money on behalf of end-users) are in the individual flow. If you’re paying your own suppliers/payroll from your own balances, you’re in the business / treasury flow. Which flow your account is in is set by Technest at onboarding, and it decides which gate applies.
These are the two common configurations, not an exhaustive partition: an account can have both flows enabled, in which case the gate follows each payout rather than the account — see Both flows enabled below.
Individual flow (this section)
End-to-end, all via the public API:
- Onboard —
POST /v1/customerswithtype: individual.id_expiry_dateis required (the banking partner needs it to provision a virtual account and it can’t be added after verification). - Verify — upload identity documents. Verification is automatic once documents are attached (a few minutes, up to ~2h).
POST /v1/customers/{id}/kycis an acknowledgement, not a separate submit. - Collect — issue the end-user their own VIBAN (GBP/USD/EUR) or use CAD Interac.
- Send —
POST /v1/payoutswithsender_customer_id= the verified end-user. Funds leave the end-user’s own account. See the payouts reference.
Business / treasury flow
The merchant entity is onboarded as a business customer with Technest (KYB — beneficial owners + business documents, reviewed in roughly 1–5 business days). Once live, the merchant sends international payouts in treasury mode: no per-payout sender_customer_id — the sender is your merchant entity. The GBP/USD/EUR gate checks your merchant international account (no_active_international_account).
Swappr resolves the sender to your merchant treasury customer automatically, so for an account configured for this flow only, sending a per-payout sender_customer_id is rejected with customer_id_mismatch. If your account is configured to require sender identity, supply it with an inline sender block. See sender attribution for the full contract and error codes.
Business KYB onboarding (owners + KYB documents) is completed with Technest, not self-serve via this API today. Contact support@the-technest.com to start.
Both flows enabled
Technest can enable a single account for both flows. Where that applies, sender_customer_id is optional, and it selects the flow per payout:
| You send | Attributed to | Funds leave | GBP/USD/EUR gate |
|---|---|---|---|
sender_customer_id | That end-user | The end-user’s own account | sender_account_not_provisioned |
| No per-payout sender | Your treasury customer | The merchant’s international account | no_active_international_account |
customer_id_mismatch does not apply to this configuration — supplying a sender is a valid instruction, not an error. CAD is exempt from both gates on either of its rails.
This is a Technest-configured capability, not a per-request option, and the business half carries the same KYB prerequisite as the flow above. Contact support@the-technest.com if you need it.
Saving recipients works for both
POST /v1/beneficiaries only requires the international-accounts feature flag — not an international account in that currency. A beneficiary is a sender-agnostic saved recipient; whether funds can actually move depends on the sender at payout time (the gates above). The capability check lives in POST /v1/payouts, not at recipient-save time.