# Recipients

After creating a quote, your application next needs to allow users to choose who will receive the funds, often referred to as the recipient or beneficiary.

The user can accomplish this either by selecting a previously created recipient creating a new one. The data needed to create a new recipient is dependent on a number of factors, which is why we recommend using our dynamic forms solution to request the required fields.

Once the recipientID is known, your application is ready to create a transfer.

## List current recipients 

Each profile contains a list of active recipients that the user has previously sent funds to. Your application should [list recipients by currency](/api-reference/recipient/recipientlist) to present a list of recipients to the user along with the ability to create a new recipient.

Once the user selects a recipient, your application should then update the quote with the selected recipient.

## Create a new recipient 

When creating a new recipient, there are a number of factors to consider, such as the currency pair, where the account is based, the amount of the transfer, and many more items. Additionally, these factors can change on a regular basis, meaning creating and maintaining recipient accounts can be difficult.

To make recipeint creation more managable, Wise has prepared a set of dynamic forms that work in a predictable and functional way. This allows you to rely on a single endpoint to retrieve the details required for a particular quote so you can display that to your users.

The [Account Requirements Dynamic Forms API reference](/api-reference/recipient/recipientaccountrequirementsget) explains how to retrieve the account detail requirements, display and validate the data, and collect additional details.

Once the user has provided the details, your application creates the account using the [Create a New Recipient endpoint](/api-reference/recipient/recipientcreate).

Account Requirements Dynamic Forms are an absolute **must** for all integrations. Dynamic forms ensure your application always has the most up-to-date information for creating recipients and that the flow will have fewer errors.

Not including dynamic forms for account requirements will result in your application breaking upon a change to those requirements, with users no longer able to create or update that type of recipient. If you are concerned about including dynamic forms in your application, please speak with the Wise team.

## Verify recipient details

To optimise payment success rates and reduce the incidence of returned transfers, Wise performs a two-tier check system during recipient creation: **validation** and **verification**.

### Validation

Validation is the preliminary check performed immediately upon the `POST /v1/accounts` request. This process ensures that the submitted recipient data conforms to the required schema and regional formatting rules, such as field lengths and format checks.

If the data is malformed, the API returns an HTTP error status code and the recipient object is not created. In such cases, you must surface the specific error details to the customer to rectify the input before re-attempting the request.

### Verification

Once a recipient has passed the initial validation and been created, a more in-depth verification process is carried out to confirm details such as the existence of the account or the recipient's account number and name match the records held by the destination bank.

### Supported currencies

Recipient verification is currently active for:

* **CNY** (Chinese Yuan)
* **EUR** (Euro, for Enterprise/Embedded payouts to SEPA accounts)
* **IDR** (Indonesian Rupiah)
* **INR** (Indian Rupee)
* **KRW** (South Korean Won)


### Handling verification

The verification results are nested within the `confirmations` object of the recipient account response, which contains an `outcomes` array. The `outcomes[0].outcome` field indicates the confirmation status, such as `SUCCESS`, `FAILURE`/`PARTIAL_FAILURE`, or `COULD_NOT_CHECK`:

* `SUCCESS` indicates that verification was successful and the details are correct. The recipient is created and ready for immediate use, with no further action required.
* Other outcomes may be **blocking** and prevent the recipient from being created (even if it passed the initial validations) or **non-blocking**. Of the non-blocking outcomes, some may require additional actions, depending on the currency corridor. This is indicated by the `outcomes[0].requiresCustomerAcceptance` field:
  * If `outcomes[0].requiresCustomerAcceptance` is `false`: While a minor discrepancy may exist, the recipient is created and usable. You can choose to inform the customer of the discrepancy, but no further API call is required to proceed.
  * If `outcomes[0].requiresCustomerAcceptance` is `true`: The recipient cannot be used for a transfer without explicit approval from the customer. To move the recipient to a usable state, you must present the mismatch details found in the outcomes array to the customer. If the user chooses to update their details, you should submit the corrected data by creating a new recipient with a new `POST` call to the `/v1/accounts` endpoint. However, if the user confirms the existing details are intentional, you must perform a `PATCH` call to a [confirmation endpoint](/api-reference/recipient/recipientconfirmationsaccept) to supply the customer's explicit acceptance and unblock the account.


## Testing recipients in the Sandbox 

Because Sandbox is a test environment, there are some differences between Sandbox and Production. Please keep these in mind as you test.

While we validate some recipient account details in Sandbox, full bank detail validation can only be tested in Production.

Speak with the Wise team if you have further questions about testing recipients in Sandbox.