CNY recipient verification

Copy

• Copy for LLM

  Copy page as Markdown for LLMs
• View as Markdown

  Open this page as Markdown
• Open in ChatGPT

  Get insights from ChatGPT
• Open in Claude

  Get insights from Claude
• Connect to Cursor

  Install MCP server on Cursor
• Connect to VS Code

  Install MCP server on VS Code

When you create a CNY Alipay recipient via the Wise API, we automatically run a series of validations (format checks) and verifications (Confirmation of Payee, or CoP) before returning the response.

This guide provides details specific to the verification that occurs when creating CNY Alipay recipients.

Supported recipient types

CNY supports one recipient type only:

Step 1: Field-level validation

Field-level validation checks the format and correctness of input fields. If any fail, the recipient is not created and the API returns a validation error.

Chinese Alipay

The following validations occur when the recipient type is chinese_alipay:

Account number formats

The Alipay ID accountNumber can be either:

Email format:

• Must match pattern: ^[^\s]+@[^\s]+\.[^\s]{2,}$
• Example: user@example.com

Phone format (regional):

• China: +86 followed by digits (+8613812345678)
• Hong Kong: +852 followed by digits
• Macau: +853 followed by digits
• Taiwan: +886 followed by digits
• Global: +CC-number where CC is any country code

Sample field validation errors

{
 "errors": [
   {
     "code": "NOT_VALID",
     "path": "name/fullName",
     "message": "The name provided is not valid."
   }
 ]
}

Step 2: Verification

Verification checks both account existence (type ACCOUNT_EXISTENCE) and name matching (type NAME_MATCHING) in a single call. This step verifies the Alipay account + name pair as a unit via the Alipay API. It only runs after all field validations pass.

Unlike currencies with separate name matching, Alipay validates both the account and name together. There is no separate name matching step and no resolved name returned. We would thus return an outcomes.[].type of type ACCOUNT_EXISTENCE.

How it works

1. Wise calls the Alipay API with the recipient's Alipay ID and full name.
2. Alipay verifies that the account exists AND the name matches as a combined check.

• If the account/name combination is invalid, the outcome is blocking so recipient creation fails with an error.
• If the combination is valid, the outcome is SUCCESS.

Because Alipay validates account and name together as a unit, there is no partial matching — the result is either valid or invalid. The resolvedName and recommendedUpdates fields are always empty for CNY.

Fields checked by recipient type

Verification blocking outcomes

If verification discovers the account/name combination is invalid, this is a blocking outcome, meaning the recipient is not created.

Sample block error: Invalid account/name combination

{
  "errors": [
    {
      "code": "ALIPAY_ACCOUNT_NUMBER_NOT_MATCHED",
      "path": "account/details/accountNumber",
      "message": "Invalid recipient name or Alipay login id."
    }
  ]
}

Possible outcomes for CNY

What to do

V1 vs V2 endpoints

Both V1 and V2 endpoints run the same validations and verifications. The difference is the field naming and how the confirmation result is returned.

V2 request confirmations

When creating a recipient with V2, include the following in your request to receive the confirmations field:

{
  "type": "chinese_alipay",
  "details": { ... },
  "responseConfiguration": {
    "additionalInformation": ["CONFIRMATION_RESULT"]
  }
}

Without this, V2 will create the recipient and run all checks, but will not include the confirmations field in the response. You would then need to fetch it separately via GET /v2/accounts/{id}.

Sample payloads

All payloads below show the confirmations field as it appears in the response after creating a recipient. Because CNY Alipay is account-existence verification (account + name validated as a unit), there is no resolvedName or recommendedUpdates.

SUCCESS (account + name valid) — phone number

{
"id": 123456,
"type": "chinese_alipay",
"accountHolderName": "Wang Wei",
"details": {
 "accountNumber": "+8613812345678"
},
"confirmations": {
 "acceptedOutcomes": false,
 "acceptedAt": null,
 "quoteId": null,
 "outcomes": [
   {
     "type": "ACCOUNT_EXISTENCE",
     "outcome": "SUCCESS",
     "timestamp": "2026-03-08T10:30:00Z",
     "requiresCustomerAcceptance": false,
     "fieldsChecked": ["details/accountNumber", "accountHolderName"],
     "message": null,
     "resolvedName": null,
     "providedName": null,
     "recommendedUpdates": []
   }
 ]
}
}

SUCCESS — with email as Alipay ID

V1 response:

{
  "id": 123457,
  "type": "chinese_alipay",
  "accountHolderName": "Wang Wei",
  "details": {
    "accountNumber": "wangwei@example.com"
  },
  "confirmations": {
    "acceptedOutcomes": false,
    "acceptedAt": null,
    "quoteId": null,
    "outcomes": [
      {
        "type": "ACCOUNT_EXISTENCE",
        "outcome": "SUCCESS",
        "timestamp": "2026-03-08T10:30:00Z",
        "requiresCustomerAcceptance": false,
        "fieldsChecked": ["details/accountNumber", "accountHolderName"],
        "message": null,
        "resolvedName": null,
        "providedName": null,
        "recommendedUpdates": []
      }
    ]
  }
}

COULD_NOT_CHECK (Alipay service error)

{
  "id": 123456,
  "type": "chinese_alipay",
  "accountHolderName": "Wang Wei",
  "details": {
    "accountNumber": "+8613812345678"
  },
  "confirmations": {
    "acceptedOutcomes": false,
    "acceptedAt": null,
    "quoteId": null,
    "outcomes": [
      {
        "type": "ACCOUNT_EXISTENCE",
        "outcome": "COULD_NOT_CHECK",
        "timestamp": "2026-03-08T10:30:00Z",
        "requiresCustomerAcceptance": true,
        "fieldsChecked": ["details/accountNumber", "accountHolderName"],
        "message": "We couldn't verify the account right now. You can still proceed.",
        "resolvedName": null,
        "providedName": null,
        "recommendedUpdates": []
      }
    ]
  }
}

COULD_NOT_CHECK (service error or timeout)

Returned when an internal Wise error occurs.

Accept confirmation outcomes

The requiresCustomerAcceptance field is true when the outcome value is COULD_NOT_CHECK.

Before you can use the recipient for a transfer, you must make a PATCH request to confirm the user has acknowledged the result.

Request

Endpoint: PATCH /v1/accounts/{accountId}/confirmations or PATCH /v2/accounts/{accountId}/confirmations

Body:

{
  "acceptedOutcomes": true
}

Response after acceptance

The response mirrors the original confirmations object, but now acceptedOutcomes is true and acceptedAt contains a timestamp:

{
  "confirmations": {
    "acceptedOutcomes": true,
    "acceptedAt": "2026-03-08T10:35:00Z",
    "quoteId": null,
    "outcomes": [
      {
        "type": "ACCOUNT_EXISTENCE",
        "outcome": "COULD_NOT_CHECK",
        "timestamp": "2026-03-08T10:30:00Z",
        "requiresCustomerAcceptance": true,
        "fieldsChecked": ["details/accountNumber", "accountHolderName"],
        "message": "We couldn't verify the account right now. You can still proceed.",
        "resolvedName": null,
        "providedName": null,
        "recommendedUpdates": []
      }
    ]
  }
}

Test in the sandbox

Recipient verification for CNY Alipay can be tested in sandbox, but results depend on Alipay’s sandbox behaviour.

1. Create a recipient via POST /v1/accounts/ (or V2) with valid details.
2. Inspect the response. Check the confirmations.outcomes.outcome field.
3. If outcome requires acceptance (requiresCustomerAcceptance: true), call PATCH /v1/accounts/{id}/confirmations with {"acceptedOutcomes": true}.
4. Create a transfer using the accepted recipient.

How to trigger each verification outcome