KRW 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 KRW 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 KRW recipients.

Supported recipient types

KRW supports the following recipient types, which follow the same recipient behaviour:

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.

South Korean

The following validations occur when the recipient type is south_korean_paygate or south_korean_paygate_business:

Sample field validation errors

Invalid account number:

{
 "errors": [
   {
     "code": "NOT_VALID",
     "path": "accountNumber",
     "message": "The account number provided is invalid."
   }
 ]
}

Step 2: Verification

Verification checks account existence only (type ACCOUNT_EXISTENCE). It only runs after all field validations pass. There is no name matching for KRW. The check only validates that the account number and bank code pair is valid. We would thus return an outcomes.[].type of type ACCOUNT_EXISTENCE.

How it works

1. Wise calls the data provider service with the recipient's bank code and account number.
2. Data provider verifies that the account number is valid for the given bank.

• If the account/bank pair is invalid, the outcome is blocking and recipient creation fails with an error.
• If the account is valid, the outcome is SUCCESS.

There is no name matching step. The verification only confirms account existence. The resolvedName, providedName, and recommendedUpdates fields are always empty for KRW.

Fields checked by recipient type

The fieldsChecked paths are the same in both V1 and V2 for KRW.

Verification blocking outcomes

If verification discovers the account/bank pair is invalid, this is blocking and recipient creation fails.

Sample blocking error (Invalid account/bank pair)

{
  "errors": [
    {
      "code": "INVALID_ACCOUNT_BANK_PAIR",
      "path": "account/details/accountNumber",
      "message": "The entered account number is not valid for the selected bank."
    }
  ]
}

Possible outcomes for KRW

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.

Unlike other currencies, the fieldsChecked paths are identical between V1 and V2 for KRW because bankCode and accountNumber paths are the same in both versions.

V2 request confirmations

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

{
  "type": "south_korean_paygate",
  "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 KRW is account-existence-only, there is no resolvedName, providedName, or recommendedUpdates.

SUCCESS (account exists)

{
"id": 123456,
"type": "south_korean_paygate",
"accountHolderName": "Kim Minjun",
"details": {
 "bankCode": "088",
 "accountNumber": "1234567890"
},
"confirmations": {
 "acceptedOutcomes": false,
 "acceptedAt": null,
 "quoteId": null,
 "outcomes": [
   {
     "type": "ACCOUNT_EXISTENCE",
     "outcome": "SUCCESS",
     "timestamp": "2026-03-08T10:30:00Z",
     "requiresCustomerAcceptance": false,
     "fieldsChecked": ["details/accountNumber", "details/bankCode"],
     "message": null,
     "resolvedName": null,
     "providedName": null,
     "recommendedUpdates": []
   }
 ]
}
}

COULD_NOT_CHECK (data provider service error)

{
  "id": 123456,
  "type": "south_korean_paygate",
  "accountHolderName": "Kim Minjun",
  "details": {
    "bankCode": "088",
    "accountNumber": "1234567890"
  },
  "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", "details/bankCode"],
        "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.

For KRW, acceptance is only needed for COULD_NOT_CHECK. SUCCESS does not require acceptance, and FAILURE (invalid account/bank pair) is blocking, so there's no confirmation to accept.

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", "details/bankCode"],
        "message": "We couldn't verify the account right now. You can still proceed.",
        "resolvedName": null,
        "providedName": null,
        "recommendedUpdates": []
      }
    ]
  }
}

Test in the sandbox

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

Recipient verification is not available in the sandbox environment for KRW because the data provider is disabled in the sandbox. This means that in sandbox, verification will always return COULD_NOT_CHECK.

To test the full verification flow with actual account validation, you must test in a staging or production-like environment. Contact the Wise team for testing options.

Expected outcomes in production