Recipient Account

Recipient or beneficiary is the one who will receive the funds.

Recipient account endpoints use a mixture of our v1 and v2 APIs. Please ensure you address the right version to get the expected results.

All recipient IDs are cross compatible with v1 and v2.
Endpoints
POST/v1/accounts
POST/v1/refund-accounts
GET/v2/accounts
DELETE/v2/accounts/{{accountId}}
GET/v1/quotes/{{quoteId}}/account-requirements

The v2 resource provides useful features such as the accountSummary and longAccountSummary field which can be used to represent the recipient's details in your UI. displayFields array allows you to build an UI containing all the dynamic fields of a recipient individually.

Additionally, the resource also includes a hash of a recipient, which can be used to track recipient details changes. This is a security feature to allow you to re-run any checks your system does on the recipient to validate them against, for example, fraud engines. The hash will remain constant unless the recipient's name or information in the details object changes.

Fields
idinteger

ID of the recipient

creatorIdinteger

Account entity that owns the recipient account

profileIdinteger

Specific profile that owns the recipient account

nameobject

Recipient name details

name.fullNametext

Recipient full name

name.givenNametext

Recipient first name

name.familyNametext

Recipient surname

name.middleNametext

Recipient middle name

currencytext

3 character currency code

countrytext

2 character country code

typetext

Recipient type

legalEntityTypetext

Entity type of recipient

statusboolean

Status of the recipient

detailstext

Account details

details.referencetext

Recipient reference (GBP example)

details.sortCodetext

Recipient bank sort code (GBP example)

details.accountNumbertext

Recipient bank account no (GBP example)

details.hashedByLooseHashAlgorithmtext

Recipient account hash

commonFieldMapobject

Map of key lookup fields on the account

commonFieldMap.bankCodeFieldtext

Bank sort code identifier field

hashtext

Account hash for change tracking

accountSummarytext

Summary of account details for ease of lookup

accountSummarytext

Summary of account details for ease of lookup

longAccountSummarytext

Account details summary

displayFieldsobject

Lookup fields

displayFields.keyobject

Account identifier key name

displayFields.labelobject

Account identifier display label

displayFields.valueobject

Account identifier value

ownedByCustomerboolean

If recipient account belongs to profile owner

Recipient Account Object
{
"id": 40000000,
"creatorId": 41000000,
"profileId": 30000000,
"name": {
"fullName": "John Doe",
"givenName": null,
"familyName": null,
"middleName": null,
"patronymicName": null,
"cannotHavePatronymicName": null
},
"currency": "GBP",
"country": "GB",
"type": "SortCode",
"legalEntityType": "PERSON",
"active": true,
"details": {
"reference": null,
"accountNumber": "37778842",
"sortCode": "040075",
"hashedByLooseHashAlgorithm": "ad245621b974efa3ef870895c3wer419a3f01af18a8a5790b47645dba6304194"
},
"commonFieldMap": {
"accountNumberField": "accountNumber",
"bankCodeField": "sortCode"
},
"hash": "666ef880f8aa6113fa112ba6531d3ed2c26dd9fgbd7de5136bfb827a6e800479",
"accountSummary": "(04-00-75) 37778842",
"longAccountSummary": "GBP account ending in 8842",
"displayFields": [
{
"key": "details/sortCode",
"label": "UK sort code",
"value": "04-00-75"
},
{
"key": "details/accountNumber",
"label": "Account number",
"value": "37778842"
}
],
"isInternal": false,
"ownedByCustomer": false
}

Recipient is a person or institution who is the ultimate beneficiary of your payment.

Recipient data includes three data blocks.

1) General Data

  • Recipient full name
  • Legal type (private/business)
  • Currency
  • Owned by customer

Owned by customer is an optional boolean to flag to record whether this recipient is the same entity (person or business) as the one sending the funds. i.e. A user sending money to their own bank account in another country/currency. This field can be used to separate these recipients in your UI, however we do not recommend this as it adds unnecessary complexity to the solution. It is safe to ignore this field and display recipients with both true and false values.

2) Bank account data

There are many different variations of bank account details needed depending on recipient target currency. For example:

  • GBP — sort code and account number
  • BGN, CHF, DKK, EUR, GEL, GBP, NOK, PKR, PLN, RON, SEK — IBAN
  • USD — routing number, account number, account type
  • INR — IFSC code, account number
  • etc.

3) Address data Recipient address data is required only if target currency is USD, PHP, THB or TRY, or if the source currency is USD or AUD.

  • Country
  • State (US, Canada, Brazil)
  • City
  • Address line
  • Zip code

When creating recipient, the following general rules should be applied to "accountHolderName" field:

  • Full names for personal recipients. They must include more than one name, and both first and last name must have more than one character. Numbers are not allowed in personal recipient names.
  • Business names must be in full, but can be just a single name. The full name cannot be just a single character but can be made up of a set of single characters. e.g. "A" is not permitted but "A 1" or "A1" is permitted.
  • Special characters _()'*,. are allowed for personal and business names.
  • In general the following regex describes our permitted characters for a name: [0-9A-Za-zÀ-ÖØ-öø-ÿ-_()'*,.\s].

Recipient requirements will vary depending on recipient type. A GBP example is provided here.
As you can see many of the fields are null, in order to know which fields are required for which currency we expose the Recipients Requirements endpoint.

Request

POST /v1/accounts

currencytext

3 character currency code

typetext

Recipient type

profileinteger

Personal or business profile ID. It is highly advised to pass the business profile ID in this field if your business account is managed by multiple users, so that the recipient can be accessed by all users authorized on the business account.

accountHolderNametext

Recipient full name

ownedByCustomerboolean

Whether this account is owned by the sending user

detailsobject

Currency specific fields

details.legalTypetext

Recipient legal type: PRIVATE or BUSINESS

details.sortCodetext

Recipient bank sort code (GBP example)

details.accountNumbertext

Recipient bank account no (GBP example)

Response

A complete Recipient object is returned when created.

Example Request - GBP Recipient
curl -X POST https://api.sandbox.transferwise.tech/v1/accounts \
-H 'Authorization: Bearer <your api token>' \
-H 'Content-Type: application/json' \
-d '{
"currency": "GBP",
"type": "sort_code",
"profile": 30000000,
"ownedByCustomer": true,
"accountHolderName": "John Doe",
"details": {
"legalType": "PRIVATE",
"sortCode": "040075",
"accountNumber": "37778842"
}
}'

POST /v1/refund-accounts

Sometimes we may need to refund the transfer back to the sender - see the transfer status here for cases when this may happen.

A refund recipient is a person or institution where we will refund transfer the money back to if necessary. This is not always a mandatory resource to create. If the funds are sent over a fast local payment network we can usually infer the refund recipient from the bank transaction that funded the transfer. Please discuss this with your Wise implementation team if you are unsure if the refund recipient is needed.

If funds are sent using a slow domestic payment network, or you are using a bulk settlement model, we may require you to share the bank details of the source bank account.

Response

A complete Recipient object is returned when created.

The refund recipient account ID returned here is used as sourceAccount when creating transfers.

The format of the request payload for refund recipient creation will be different depending on the currency you will send transfers from. This example is for GBP only. We can provide the correct format for your region upon request.

Example Request - GBP Refund Recipient
curl -X POST https://api.sandbox.transferwise.tech/v1/refund-accounts \
-H 'Authorization: Bearer <your api token>' \
-H 'Content-Type: application/json' \
-d '{
"currency": "GBP",
"country": "GB",
"type": "sort_code",
"profile": 30000000,
"legalEntityType": "PERSON",
"name": {
"fullName": "John Doe"
},
"details": {
"sortCode": "040075",
"accountNumber": "37778842"
}
}'

POST /v1/accounts

Please contact us before attempting to use email recipients. We do not recommend using this feature except for certain uses cases.

If you don't know recipient bank account details you can set up an email recipient; Wise will collect bank details directly from the recipient.

Wise will email your recipient with a link to collect their bank account details securely. After the bank account details have been provided Wise will complete your transfer.

Please be aware of the following caveats:

  • Testing of transfers to email recipients in sandbox is not currently possible.
  • Recipients will be required to enter bank details every time a payment is made.
  • We highly encourage you to provide the profileId if your recipient is receiving a payment from your Business account, especially if you have multiple businesses, or have multiple users administrating your business account.
  • Please refer to our help page on how this works and any additional constraints not mentioned in this section.

Response

A complete Recipient object is returned when created.

Example Request - EUR Email Recipient
curl -X POST https://api.sandbox.transferwise.tech/v1/accounts \
-H 'Authorization: Bearer <your api token>' \
-H 'Content-Type: application/json' \
-d '{
"profile": 30000000,
"accountHolderName": "John Doe",
"currency": "EUR",
"type": "email",
"details": {
"email": "john.doe@transfer-world.com"
}
}'

GET /v2/accounts?profileId={{profileId}}&currency={{currency}}

Fetch a list of the user's recipient accounts. Use the profileId parameter to filter by the profile who created the accounts, you should do this based on the personal or business profile ID you have linked to, based on your use case. Other filters are listed below for your convenience, for example currency is a useful filter to use when presenting the user a list of recipients to chose from in the case they have already submitted the target currency of their in your flow.

Pagination

Pagination is supported for this endpoint. The response includes the seekPositionForNext and size parameters to manage this.

It works by setting size and seekPosition parameters in the call. Set the value in the seekPositionForNext of the previous response into the seekPosition parameter of your subsequent call in order to get the next page. To get the current page again, use the seekPositionForCurrent value.

Sorting

You can also set the sort parameter to control the sorting of the response, for example:

?sort=id,asc sort by id ascending.
?sort=id,desc sort by id descending.
?sort=currency,asc sort by currency ascending.

All query parameters are optional.

Query Parameters
creatorIdinteger

Creator of the account.

profileIdinteger

Filter by personal or business profile, returns only those owned by this profile. Defaults to the personal profile.

currencytext

Filter responses by currency, comma separated values are supported (e.g. USD,GBP).

activeboolean

Filter by whether this profile is active. Defaults to true.

typetext

Filter responses by account type, comma separated values are supported (e.g. iban,swift_code).

ownedByCustomerboolean

Filter to get accounts owned by the customer or not, leave out to get all accounts.

sizeinteger

Page size of the response. Defaults to a maximum of 20.

seekPositioninteger

Account ID to start the page of responses from in the response. null if no more pages.

sortinteger

Sorting strategy for the response. Comma separated options: firstly either id or currency, followed by asc or desc for direction.

Response

An array of Recipient objects is returned.

Example Request
curl -X GET https://api.sandbox.transferwise.tech/v2/accounts?profile={{profileId}}&currency={{currency}} \
-H 'Authorization: Bearer <your api token>'
Example Response
{
"content": [
{
"id": 40000000,
"creatorId": 41000000,
"profileId": 30000000,
"name": {
"fullName": "John Doe",
"givenName": null,
"familyName": null,
"middleName": null,
"patronymicName": null,
"cannotHavePatronymicName": null
},
"currency": "GBP",
"country": "GB",
"type": "SortCode",
"legalEntityType": "PERSON",
"active": true,
"details": {
"reference": null,
"accountNumber": "37778842",
"sortCode": "040075",
"hashedByLooseHashAlgorithm": "ad245621b974efa3ef870895c3wer419a3f01af18a8a5790b47645dba6304194"
},
"commonFieldMap": {
"accountNumberField": "accountNumber",
"bankCodeField": "sortCode"
},
"hash": "666ef880f8aa6113fa112ba6531d3ed2c26dd9fgbd7de5136bfb827a6e800479",
"accountSummary": "(04-00-75) 37778842",
"longAccountSummary": "GBP account ending in 8842",
"displayFields": [
{
"key": "details/sortCode",
"label": "UK sort code",
"value": "04-00-75"
},
{
"key": "details/accountNumber",
"label": "Account number",
"value": "37778842"
}
],
"isInternal": false,
"ownedByCustomer": false
}
],
"sort": {
"empty": true,
"sorted": false,
"unsorted": true
},
"size": 1
}

GET /v2/accounts/{{accountId}}

V1 and v2 versions are cross compatible, but the v2 endpoint provides some additional features.
Read more

Get recipient account info by ID.

Response

A Recipient object is returned.

Example Request
curl -X GET https://api.sandbox.transferwise.tech/v2/accounts/{{accountId}} \
-H 'Authorization: Bearer <your api token>'

DELETE /v2/accounts/{{accountId}}

Deletes a recipient by changing its status to inactive ("active": false). Requesting to delete a recipient that is already inactive will return an HTTP status 403 (forbidden).

Only active recipients can be deleted and a recipient cannot be reactivated, however you can create a new recipient with the same details instead if necessary.

Response

A complete Recipient object is returned, with the value of active set to false.

Example Request
curl -X DELETE https://api.sandbox.transferwise.tech/v2/accounts/{{accountId}} \
-H 'Authorization: Bearer <your api token>'
Please note that to use v1.1 Accept-Minor-Version: 1 request header must be set.

Request

GET /v1/quotes/{{quoteId}}/account-requirements
POST /v1/quotes/{{quoteId}}/account-requirements
GET /v1/account-requirements?source=EUR&target=USD&sourceAmount=1000

You can use the data returned by this API to build a dynamic user interface for recipient creation. The GET and POST account-requirements endpoints help you to figure out which fields are required to create a valid recipient for different currencies. This is a step-by-step guide on how these endpoints work.

Use the GET endpoint to learn what datapoints are required to send a payment to your beneficiary. As you build that form, use the POST endpoint to learn if any additional datapoints are required as a result of passing a field that has "refreshRequirementsOnChange": true' in the GET response. You should be posting the same recipient account payload that will be posted to v1/accounts.

An example of this would be address.country. Some countries, like the United States, have a lower level organization, "state" or "territory". After POSTing the recipient payload with address.country = "US", the list of possible states will appear in the response.

The third endpoint above is used to get account requirements for a specific currency route and amount without referring to a quote but with the amount, source and target currencies passed as URL parameters. Generally this approach is not recommended, you should have your user create a quote resource first and use this to generate the recipient account requirements. This is because some payout methods will only surface when the profile-context is known, for example (at the time of this writing), Business Payments to Chinese Yuan use a different payout method than what is revealed by GET /v1/account-requirements?source=USD&target=CNY&sourceAmount=1000.

All new integrations should use the v1.1 of GET and POST account requirements, enabled using the Accept-Minor-Version header. It enables you to fetch the requirements including both the recipient name and email fields in the dynamic form, simplifying implementation of the form. Name and email address dynamic fields are required to support currencies such as KRW, JPY and RUB, and also remove the need for manual name validation.

These endpoints allow use of both v1 and v2 quotes using long or UUID based IDs, supporting legacy implementations using v1 quotes.

Using account requirements

Response
typetext

"address"

fields[n].nametext

Field description

fields[n].group[n].keytext

Key is name of the field you should include in the JSON

fields[n].group[n].typetext

Display type of field. Can be text, select, radio or date

fields[n].group[n].refreshRequirementsOnChangeboolean

Tells you whether you should call POST account-requirements once the field value is set to discover required lower level fields.

fields[n].group[n].requiredboolean

Indicates if the field is mandatory or not

fields[n].group[n].displayFormattext

Display format pattern.

fields[n].group[n].exampletext

Example value.

fields[n].group[n].minLengthinteger

Min valid length of field value.

fields[n].group[n].maxLengthinteger

Max valid length of field value.

fields[n].group[n].validationRegexptext

Regexp validation pattern.

fields[n].group[n].validationAsynctext

Validator URL and parameter name you should use when submitting the value for validation

fields[n].group[n].valuesAllowed[n].keytext

List of allowed values. Value key

fields[n].group[n].valuesAllowed[n].nametext

List of allowed values. Value name.

Example Request
curl -X GET https://api.sandbox.transferwise.tech/v1/quotes/{{quoteId}}/account-requirements \
-H 'Authorization: Bearer <your api token>' \
-H 'Accept-Minor-Version: 1'

Collecting Recipient Address

Normally our account requirements will instruct when a recipient address is required. However, in some situations it's desirable to force the requirement so that an address can be provided to Wise. To do this, add the query parameter ?addressRequired=true to your request and address will always be returned as a required field.

The JSON snippets are just example to illustrate demonstrating the recipient address fields. These fields are subject to change. Your integration should be built in a way to handle unrecognized or changed fields.
recipient.address requirements example
...
{
"name": "Country",
"group": [
{
"key": "address.country",
"name": "Country",
"type": "select",
"refreshRequirementsOnChange": true,
"required": true,
"displayFormat": null,
"example": "Choose a country",
"minLength": null,
"maxLength": null,
"validationRegexp": null,
"validationAsync": null,
"valuesAllowed": [
#list of countries
]
}
]
},
{
"name": "City",
"group": [
{
"key": "address.city",
"name": "City",
"type": "text",
"refreshRequirementsOnChange": false,
"required": true,
"displayFormat": null,
"example": "",
"minLength": 1,
"maxLength": 255,
"validationRegexp": "^.{1,255}$",
"validationAsync": null,
"valuesAllowed": null
}
]
},
{
"name": "Recipient address",
"group": [
{
"key": "address.firstLine",
"name": "Recipient address",
"type": "text",
"refreshRequirementsOnChange": false,
"required": true,
"displayFormat": null,
"example": "",
"minLength": 1,
"maxLength": 255,
"validationRegexp": "^.{1,255}$",
"validationAsync": null,
"valuesAllowed": null
}
]
},
{
"name": "Post code",
"group": [
{
"key": "address.postCode",
"name": "Post code",
"type": "text",
"refreshRequirementsOnChange": false,
"required": true,
"displayFormat": null,
"example": "",
"minLength": 1,
"maxLength": 32,
"validationRegexp": "^.{1,32}$",
"validationAsync": null,
"valuesAllowed": null
}
]
},
...
Example Response from /account-requirements
[
{
"type": "south_korean_paygate",
"title": "PayGate",
"usageInfo": null,
"fields": [
{
"name": "E-mail",
"group": [
{
"key": "email",
"name": "E-mail",
"type": "text",
"refreshRequirementsOnChange": false,
"required": true,
"displayFormat": null,
"example": "example@example.ex",
"minLength": null,
"maxLength": null,
"validationRegexp": "^[^\\s]+@[^\\s]+\\.[^\\s]{2,}$",
"validationAsync": null,
"valuesAllowed": null
}
]
},
{
"name": "Recipient type",
"group": [
{
"key": "legalType",
"name": "Recipient type",
"type": "select",
"refreshRequirementsOnChange": false,
"required": true,
"displayFormat": null,
"example": "",
"minLength": null,
"maxLength": null,
"validationRegexp": null,
"validationAsync": null,
"valuesAllowed": [
{
"key": "PRIVATE",
"name": "Person"
}
]
}
]
},
{
"name": "Full Name",
"group": [
{
"key": "accountHolderName",
"name": "Full Name",
"type": "text",
"refreshRequirementsOnChange": false,
"required": true,
"displayFormat": null,
"example": "",
"minLength": 2,
"maxLength": 140,
"validationRegexp": "^[0-9A-Za-zÀ-ÖØ-öø-ÿ-_()'*,.%#^@{}~<>+$\"\\[\\]\\\\ ]+$",
"validationAsync": null,
"valuesAllowed": null
}
]
},
{
"name": "Recipient's Date of Birth",
"group": [
{
"key": "dateOfBirth",
"name": "Recipient's Date of Birth",
"type": "date",
"refreshRequirementsOnChange": false,
"required": true,
"displayFormat": null,
"example": "",
"minLength": null,
"maxLength": null,
"validationRegexp": "^\\d{4}\\-\\d{2}\\-\\d{2}$",
"validationAsync": null,
"valuesAllowed": null
}
]
},
{
"name": "Recipient Bank Name",
"group": [
{
"key": "bankCode",
"name": "Recipient Bank Name",
"type": "select",
"refreshRequirementsOnChange": false,
"required": true,
"displayFormat": null,
"example": "Choose recipient bank",
"minLength": null,
"maxLength": null,
"validationRegexp": null,
"validationAsync": null,
"valuesAllowed": [
{
"key": "",
"name": "Choose recipient bank"
},
...
]
}
]
},
{
"name": "Account number (KRW accounts only)",
"group": [
{
"key": "accountNumber",
"name": "Account number (KRW accounts only)",
"type": "text",
"refreshRequirementsOnChange": false,
"required": true,
"displayFormat": null,
"example": "1254693521232",
"minLength": 10,
"maxLength": 16,
"validationRegexp": null,
"validationAsync": null,
"valuesAllowed": null
}
]
}
]
},