GBP payouts

Send GBP to UK bank accounts over the Faster Payments rail, settled from your GBP international account. Recipients are identified by account number + sort code.

See the Payouts overview for common fields, customer attribution, and the shared payout object + management endpoints (documented on the NGN page).

Want the exact fee before you send? Preview it with POST /v1/payouts/quote — an advisory, read-only fee + cost breakdown for your account.

Prerequisites

International accounts enabled on your merchant account.
An active GBP account to send from. In the individual flow this is the sender’s own virtual account (sender_account_not_provisioned if missing); in the business/treasury flow it’s your merchant international account (no_active_international_account if missing). If your account is configured for both flows, the account checked follows the payout — see sender attribution. See the error table.
A sender for compliance — how you supply it depends on your flow: the individual flow passes sender_customer_id on every payout; the business/treasury flow passes no per-payout sender; an account configured for both passes it or omits it per payout. See below.
For attribution reads on GET /v1/customers/{id}/transactions: the API key needs customer_transaction_view.

POSTSave a GBP beneficiary, then pay by reference

POST/v1/beneficiaries

The reliable path for FX is to save the recipient once via POST /v1/beneficiaries, then reference it by beneficiary_id on each payout. A saved GBP beneficiary captures the address the receiving network needs (the inline path below does not), so payouts settle cleanly.

Returns a beneficiary with an id (e.g. ben_…). Idempotent — re-saving the same recipient returns the existing record with created: false.

Request

curl https://api.swappr.me/api/v1/beneficiaries \
  -H "Authorization: Bearer sk_test_..." \
  -H "Idempotency-Key: $(uuidgen)" \
  -H "Content-Type: application/json" \
  -d '{
    "currency": "GBP",
    "name": "Jane Doe",
    "bank": {
      "account_number": "12345678",
      "sort_code": "200000",
      "bank_name": "Barclays"
    },
    "address": {
      "street": "10 Downing Street",
      "city": "London",
      "zip_code": "SW1A 2AA"
    },
    "external_reference": "supplier-42"
  }'

POSTCreate a GBP payout

POST/v1/payouts

amount_minor is in pence (150000 = £1,500.00). Prefer the by-beneficiary path; the inline recipient is soft-deprecated for FX and does not carry address details.

Required recipient fields

Path	Field	Required	Notes
Beneficiary	`bank.account_number`	yes	UK account number (8 digits).
Beneficiary	`bank.sort_code`	yes	6-digit sort code.
Beneficiary	`address.street` / `address.city` / `address.zip_code`	yes	Receiving-network compliance.
Beneficiary	`name`	yes	Recipient name.
Inline	`recipient.account_number`	yes	8 digits.
Inline	`recipient.sort_code`	yes	6 digits.
Inline	`recipient.name`	yes	Recipient name.
Inline	`recipient.bank_name`	yes	Recipient’s bank name.
Inline	`recipient.email`	yes	Recipient email.
Inline	`recipient.street` / `recipient.city` / `recipient.country`	yes	Recipient address (`country` as ISO 3166-1 alpha-2, e.g. `GB`).
Inline	`recipient.zip_code`	yes	Postal code.

The full recipient identity + address is now required for GBP (previously some fields were accepted only when supplied). This guarantees the payout is deliverable regardless of which network routes it. recipient.state (county) stays optional for GB.

Sender attribution

GBP requires the sending customer to be identified for compliance, and how you identify them depends on your flow.

Individual flow — pass sender_customer_id on every payout (the id of a customer created via POST /v1/customers); Swappr resolves their stored KYC. It is required — an inline sender block does not substitute for it, and omitting it returns missing_field. You may still send an inline sender alongside it: the two are complementary, inline fields winning per-field while the referenced customer’s stored KYC backfills any you omit.

Business / treasury flow — omit sender_customer_id. The sender is your merchant treasury customer, resolved automatically. If only this flow is enabled on your account, sending one anyway returns customer_id_mismatch. If your account is configured to require sender identity, supply it with an inline sender block.

Both flows enabled — if Technest has enabled both flows on your account, sender_customer_id is optional, and it selects the flow per payout. Supply it and the payout is attributed to that end customer and leaves the sender’s own account (sender_account_not_provisioned if they have none). Omit it and the payout is attributed to your treasury customer and leaves your merchant international account (no_active_international_account if you have none). customer_id_mismatch does not apply — supplying a sender is a valid instruction for this configuration, not an error. This is a Technest-configured capability, not a per-request option.

customer_id (optional, for attribution) must match sender_customer_id if both are supplied, or the request is rejected with customer_id_mismatch.

Response

201 Created with the payout object (currency: "GBP"). Status is queued / processing, transitioning to paid when the network confirms — listen for the payout.paid webhook.

Errors

Code	HTTP	Cause
`fx_features_not_enabled`	403	International accounts not enabled for this merchant
`no_active_international_account`	403	(Business/treasury) No active merchant GBP international account
`sender_account_not_provisioned`	422	(Individual) The sending customer has no active GBP virtual account — issue one via `POST /v1/customers/{id}/virtual_accounts`
`missing_field`	400/422	Required recipient field absent — `recipient.account_number`, `recipient.sort_code`, `recipient.name`, `recipient.bank_name`, `recipient.email`, `recipient.street`, `recipient.city`, `recipient.country`, `recipient.zip_code`
`beneficiary_not_found`	404	`beneficiary_id` unknown / not yours / wrong env
`beneficiary_currency_mismatch`	400	`beneficiary_id` is not a GBP beneficiary
`missing_field`	400	(Individual) `sender_customer_id` absent — it is required on FX payouts and an inline `sender` block does not substitute. Returned before `sender_info_required`.
`sender_info_required`	422	Your account is configured to require sender identity and the merged sender details (inline `sender` block + the referenced customer’s stored KYC) are still incomplete
`customer_id_mismatch`	400	`customer_id` ≠ `sender_customer_id` — or a business/treasury-only account sent a per-payout `sender_customer_id` (omit it; the sender is your treasury customer). The second cause does not apply to an account configured for both flows
`no_treasury_customer`	400	(Business/treasury) Your treasury customer isn’t provisioned yet — contact Technest to set up your international payouts
`idempotency_key_conflict`	409	Same `Idempotency-Key`, different body
`idempotency_conflict`	409	Same `Idempotency-Key` as a prior payout that differs in amount or recipient account — narrower than `idempotency_key_conflict`, which compares the whole request body
`merchant_reference_duplicate`	409	`merchant_reference` was already used on a recent payout; each reference is single-use within the cool-down window
`insufficient_funds`	402	Wallet balance is below the payout amount plus fees
`wallet_frozen`	403	The source wallet is frozen; no debits are permitted
`beneficiary_blacklisted`	403	Recipient is on your merchant blacklist — un-blacklist them on the Beneficiaries page, or send to a different recipient
`beneficiary_globally_blocked`	403	Recipient is on the platform-wide blacklist and cannot be overridden — contact support
`provider_not_entitled`	403	Your account isn’t enabled to send this currency through any configured route — contact Technest to enable it. Distinct from `routing_failed`: routes exist, your account is not enabled for them
`provider_paused`	403	Sending this currency is temporarily paused on your account — contact Technest. Distinct from `provider_not_entitled`: your account is enabled for a route, but Technest has paused it
`routing_failed`	422	No disbursement route is available for this payout at all, or the destination bank could not be identified
`beneficiary_cooldown`	429	Same recipient paid recently — pass `allow_duplicate: true` if intentional
`provider_error`	502	Downstream rail unreachable; safe to retry with the same key

Shared management endpoints (list / retrieve / requery / cancel) are on the NGN page.

Request — by beneficiary (preferred)

curl https://api.swappr.me/api/v1/payouts \
  -H "Authorization: Bearer sk_test_..." \
  -H "Idempotency-Key: $(uuidgen)" \
  -H "Content-Type: application/json" \
  -d '{
    "amount_minor": "150000",
    "currency": "GBP",
    "beneficiary_id": "ben_cmo8x2p9q0...",
    "sender_customer_id": "cust_cmoji8...",
    "customer_id": "cust_cmoji8...",
    "merchant_reference": "INV-2026-04"
  }'

Request — inline recipient (soft-deprecated for FX)

curl https://api.swappr.me/api/v1/payouts \
  -H "Authorization: Bearer sk_test_..." \
  -H "Idempotency-Key: $(uuidgen)" \
  -H "Content-Type: application/json" \
  -d '{
    "amount_minor": "150000",
    "currency": "GBP",
    "recipient": {
      "name": "Jane Doe",
      "account_number": "12345678",
      "sort_code": "200000",
      "bank_name": "Barclays",
      "email": "jane.doe@example.com",
      "street": "10 Downing Street",
      "city": "London",
      "country": "GB",
      "zip_code": "SW1A 2AA"
    },
    "sender_customer_id": "cust_cmoji8...",
    "merchant_reference": "INV-2026-04"
  }'

Webhook events

payout.processing → payout.paid or payout.failed (and payout.reversed on a later reversal). customer_id / customer_reference are included when set. See Webhooks.

NGN USD