Recipient Account

These endpoints use a mixture of our v1 and v2 api - please ensure you address the right version to get the expected results. All recipient IDs are cross compatible with v1 and v2.

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

Response

A complete Recipient object is returned when created.

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. In order to do this we have the following API:

Response

A complete Recipient object is returned when created.

The refund recipient account id returned here is needed when creating transfers in step 3 as the field sourceAccount in the POST /v1/transfers call.

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

POST /v1/accounts

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.

GET /v1/accounts/{{accountId}}

Get recipient account info by id.

Response

A complete Recipient object is returned when created.

This response also includes a hash of a recipient, this can be used to track if the recipient details change, which they can in some scenarios. 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.

GET /v1/accounts?profile={{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.

Response

An array of complete Recipient objects is returned.

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).

Response

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

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. Set the request header Accept-Minor-Version to 1 to use this version.

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

Using account requirements