To improve transparency, we're introducing four RFI sub-statuses that sit beneath the existing under_review main status. These sub-statuses are opt-in and exposed as an additional field in the API response and via a dedicated webhook — existing integrations are not affected unless you choose to use the new field.

New Sub-Statuses​

1. RFI Required
   • Code : rfi_required
   • Definition : We are waiting for the customer to provide additional information or documents.
   • Behavior : Set on the first transition to the internal awaiting-customer-response state. Not repeated on subsequent back-and-forth within the same RFI case.
2. RFI Ongoing
   • Code : rfi_ongoing
   • Definition : The customer has provided information and the case is under compliance or screening review.
   • Behavior : Set on the first transition from awaiting-customer-response back to undergoing-screening. Not repeated on minor internal updates.
3. RFI Approved
   • Code : rfi_approved
   • Definition : The RFI review passed and the transaction can move forward.
   • Behavior : Indicates a positive outcome of the RFI review. Does not guarantee the transaction will proceed to processing — the main status transitions are handled separately.
4. RFI Rejected
   • Code : rfi_rejected
   • Definition : The RFI review failed and the transaction will be rejected.
   • Behavior : Indicates a negative outcome of the RFI review. The transaction is expected to be rejected.

Sub-Status Summary​

What's Changing​

• Payment Retrieve and Payment Listing responses will include an additional RFI sub-status field when an RFI is active and the client has this feature enabled.
• A new RFI sub-status webhook is sent whenever the RFI state changes, so you can update your UI or operational workflows without polling.
• The main under_review status is unchanged. Clients who do not enable RFI sub-status will continue to see only under_review as before.

Important Notes​

• RFI sub-statuses only reflect internal compliance RFI. RFI raised by external parties is a separate flow and is not covered by these sub-statuses.
• An RFI Required or RFI Ongoing sub-status does not indicate the final outcome — the transaction may still be approved or rejected after review.
• This feature is off by default for all clients. Contact your account manager or raise an internal request to have it enabled for your account.

Action Required​

• If you want to use RFI sub-statuses, request enablement through your account manager.
• Once enabled, update your integration to read the new RFI sub-status field from Payment Retrieve and Payment Listing responses.
• Subscribe to and handle the new RFI sub-status webhook to receive real-time updates.
• If you take no action, your existing integration continues to function as today.

Release Schedule​

• Staging : 17 June 2026
• Production : 17 June 2026

API Reference​

• Payment Retrieve
• Payment Listing
• Payment Status Notification

To improve clarity, we’re introducing two new statuses — withdrawn and terminated — and renaming inactive to closed.

New Statuses​

1. Withdrawn
   • Code : withdrawn
   • Definition : The member account did not complete the onboarding process within the stipulated timeline, resulting in a drop-off.
   • Behavior : Returned when an account did not complete onboarding but was not formally rejected or approved.
2. Terminated
   • Code : terminated
   • Definition : The member account was previously approved but has since been formally terminated due to operational reasons.
   • Behavior : Returned when a previously approved account is no longer active due to Wallex-initiated termination.

Renamed Status​

• Closed
  • Code : closed
  • Previous code : inactive
  • Definition : The previously approved member account has been closed upon the client’s request.
  • Behavior : Returned when an approved account is no longer active because the client formally requested account closure.

Status Summary​

Action Required​

• Review your account and user status-handling logic to include withdrawn, terminated, and closed.
• If you filter, map, or display account or user statuses in your system, ensure these new values are supported.
• Replace any usage of inactive with closed.

Release Schedule​

• Staging : 13 May 2026
• Production : 15 August 2026

API Reference​

• Users Overview

By including the X-Idempotency-Key header in your request, the server will store the key for 12 hours. Within this period, any subsequent request with the same key will return the original response instead of creating a new account.

How It Works​

Include the X-Idempotency-Key header with a unique value (max 36 characters, preferably a UUID) in your signup request. The server responds with the following status codes based on the request state:

• 201 Created : A new account has been successfully created.
• 200 OK : A duplicate request was made with the same idempotency key, or the request was created without an idempotency key.
• 409 Conflict : Another operation with the same idempotency key is currently in progress. Wait briefly before retrying.

Omitting the X-Idempotency-Key header treats each request as a new operation.

When a cached response is returned (a duplicate request with the same idempotency key), the server will include the header X-Request-Replayed: true in the response. This allows you to distinguish between a freshly processed request and a replayed one.

Action Required​

• Update your integration to include the X-Idempotency-Key header on signup requests for safe retry handling.
• Ensure your system handles the new 201 and 409 status codes in addition to the existing 200 response.

Release Schedule​

• Staging : 2 February 2026
• Production : 2 February 2026

API Reference​

• Signup
• Signup Lite Individual
• Signup Lite Company

To improve transparency, we’re introducing two new statuses — under_review and in_transit — and redefining processing to represent a narrower and more precise stage in the Payment lifecycle.

New Statuses​

1. Under Review
   • Code : under_review
   • Definition : The funds have been received and is currently undergoing internal verification and checks.
   • Behavior : Returned when the transaction is funded but pending internal clearance before processing begins.
2. In Transit
   • Code : in_transit
   • Definition : The payment has successfully processed and is currently being routed to the payment provider for disbursement.
   • Behavior : Indicates the transaction has entered the settlement pipeline with the payment provider and is pending confirmation of payout.

Narrowed Definition of Processing​

• Before : Represented all stages after a payment was funded, including internal review and payout routing to the payment provider.
• Now : Represents the stage after internal clearance but before payout routing — when a transaction is being validated and prepared for settlement.

Action Required​

• Review your status-handling logic to include under_review and in_transit.
• If you filter or display statuses in your system, ensure these new values are supported.

The Payment API now returns clearer and more granular payment statuses. By introducing under_review and in_transit, and refining processing, API users can track payment progression with greater accuracy and confidence.

Release Schedule​

• Staging : 18 November 2025
• Production : 28 November 2025

API Reference​

• Payment Overview
• Payment Fund
• Payment Retrieve
• Payment Listing
• Payment Status Notification

Release Schedule​

• Staging : 4 November 2025
• Production : 4 November 2025

API Reference​

• Balance History Listing
• Funding Webhook
• Conversion Webhook
• Payment Webhook

Update​

We introduce the new API payload to include the following additional attributes:

• Beneficiary Entity Type
• Bank Account Number
• Bank Account SWIFT Code
• Bank Account Type
• Bank Account Branch Code
• Origin Sender Type
• Origin Sender Country

Key Considerations​

• Backward compatibility will be maintained to prevent disruption for existing integrations.

Request​

curl --location '/v2/payments/quote' \
--header 'Authorization: Bearer <X-Api-Key>' \
--header 'Content-Type: application/json' \
--header 'X-API-KEY: <X-Api-Key>' \
--data '{
    "beneficiary": {
        "country": "TH",
        "entityType": "company"
    },
    "bankAccount": {
        "country": "TH",
        "currency": "THB",
        "accountNumber": "1234567890",
        "bicSwift": "BKKBTHBK"
    },
    "originSender": {
        "country": "TH",
        "type": "company"
    },
    "sellCurrency": "SGD",
    "amount": 1000,
    "fixedSide": "sell"
}'

Beneficiary​

Bank Account​

Origin Sender​

Release Schedule​

• Staging : 26 August 2025
• Production : 26 August 2025

API Reference​

• Payment Quote (Correspondent Flow)

1. Beneficiary Requirement
2. Create a Beneficiary
3. Payment Quote
4. Create Payment

Please ensure that your integration reflects these updates to avoid disruption in PKR, INR and VND transaction processing.

Update​

We have updated the mandatory requirements for the following fields:

1. Individual
   • First Name under the attribute firstName
   • Last Name under the attribute lastName
   • Bank Account Holder Name under the attribute bankAccount.bankAccountHolderName
2. Company
   • Company Name under the attribute companyName
   • Bank Account Holder Name under the attribute bankAccount.bankAccountHolderName

Request​

curl -L '/v2/beneficiaries/requirements' \
-H 'Content-Type: application/json' \
-H 'Accept: application/json' \
-H 'X-Api-Key: <X-Api-Key>' \
-H 'Authorization: Bearer <X-Api-Key>' \
-d '{
  "currency": "VND",
  "bankAccountCountry": "VN",
  "beneficiaryCountry": "VN"
}'

Response​

{
    "data": [
        {
            "entityType": "individual",
            "firstName": "^[a-zA-Z0-9 ,.\\-'&()!\/+]+$",
            "lastName": "^[a-zA-Z0-9 ,.\\-'&()!\/+]+$",
            "identificationType": "^(NATIONAL_ID)",
            "identificationValue": "^.{1,255}",
            "relationship": "^.{1,255}",
            "address": "^.{1,255}",
            "city": "^.{1,255}",
            "country": "^[A-Z]{2}",
            "bankAccount": {
                "currency": "^[A-Z]{3}",
                "bankAccountHolderName": "^[a-zA-Z0-9~@#$%^&*()_`=\"\\[\\]{}\\|<> ,.\\-'&()!\/:+]+$",
                "accountNumber": "^[0-9A-Z]{1,50}$",
                "bicSwift": "^[0-9A-Z]{8}$|^[0-9A-Z]{11}$",
                "bankName": "^.{1,255}",
                "country": "^[A-Z]{2}"
            }
        },
        {
            "entityType": "company",
            "companyName": "^[a-zA-Z0-9~@#$%^&*()_`=\"\\[\\]{}\\|<> ,.\\-'&()!\/:+]+$",
            "address": "^.{1,255}",
            "city": "^.{1,255}",
            "country": "^[A-Z]{2}",
            "bankAccount": {
                "currency": "^[A-Z]{3}",
                "bankAccountHolderName": "^[a-zA-Z0-9~@#$%^&*()_`=\"\\[\\]{}\\|<> ,.\\-'&()!\/:+]+$",
                "accountNumber": "^[0-9A-Z]{1,50}$",
                "bicSwift": "^[0-9A-Z]{8}$|^[0-9A-Z]{11}$",
                "bankName": "^.{1,255}",
                "country": "^[A-Z]{2}"
            }
        }
    ]
}

Release Schedule​

• Staging : 18 July 2025
• Production : 25 July 2025

API Reference​

• Beneficiary Requirements
• Beneficiary Create
• Payment Quote (Correspondent Flow)
• Payment Create (Correspondent Flow)

1. Beneficiary Requirement
2. Create a Beneficiary
3. Payment Quote
4. Create Payment

Please ensure that your integration reflects these updates to avoid disruption in JPY transaction processing.

Update​

• Adjustment of Bank Account Type options under the attribute bankAccount.type. The accepted options:
  • Checking
  • Savings

Request​

curl -L '/v2/beneficiaries/requirements' \
-H 'Content-Type: application/json' \
-H 'Accept: application/json' \
-H 'X-Api-Key: <X-Api-Key>' \
-H 'Authorization: Bearer <X-Api-Key>' \
-d '{
  "currency": "JPY",
  "bankAccountCountry": "JP",
  "beneficiaryCountry": "JP"
}'

Response​

{
    "data": [
        {
            "entityType": "individual",
            "firstName": "^[a-zA-Z0-9 ,.\\-'&()!\/+]*$",
            "lastName": "^[a-zA-Z0-9 ,.\\-'&()!\/+]*$",
            "address": "^.{1,255}",
            "city": "^.{1,255}",
            "country": "^[A-Z]{2}",
            "bankAccount": {
                "currency": "^[A-Z]{3}",
                "bankAccountHolderName": "^[a-zA-Z0-9~@#$%^&*()_`=\"\\[\\]{}\\|<> ,.\\-'&()!\/:+]*$",
                "accountNumber": "^[0-9A-Z]{1,16}$",
                "type": "^$|^(Checking|Savings)",
                "bicSwift": "^[0-9A-Z]{8}$|^[0-9A-Z]{11}$",
                "bankName": "^.{1,255}",
                "branchCode": "^$|^\\d{3}$",
                "country": "^[A-Z]{2}"
            }
        },
        {
            "entityType": "company",
            "companyName": "^[a-zA-Z0-9~@#$%^&*()_`=\"\\[\\]{}\\|<> ,.\\-'&()!\/:+]*$",
            "address": "^.{1,255}",
            "city": "^.{1,255}",
            "country": "^[A-Z]{2}",
            "bankAccount": {
                "currency": "^[A-Z]{3}",
                "bankAccountHolderName": "^[a-zA-Z0-9~@#$%^&*()_`=\"\\[\\]{}\\|<> ,.\\-'&()!\/:+]*$",
                "accountNumber": "^[0-9A-Z]{1,16}$",
                "type": "^$|^(Checking|Savings)",
                "bicSwift": "^[0-9A-Z]{8}$|^[0-9A-Z]{11}$",
                "bankName": "^.{1,255}",
                "branchCode": "^$|^\\d{3}$",
                "country": "^[A-Z]{2}"
            }
        }
    ]
}

Release Schedule​

• Staging : 24 June 2025
• Production : 01 July 2025

API Reference​

• Beneficiary Requirements
• Beneficiary Create
• Payment Quote (Correspondent Flow)
• Payment Create (Correspondent Flow)

The Collection Upload URL API empowers our partners to independently upload the necessary supporting documents associated with their collections. This functionality eliminates the need for admin intervention, streamlining the integration process and enabling a faster, more seamless workflow. By using this API, partners gain greater autonomy and efficiency in managing their document uploads.

Collection Upload URL API available for v2 API.

Request​

POST /v2/collections/:id/documents
Content-Type: application/json
X-Api-Key: <X-Api-Key>
Authorization: Bearer <X-Api-Key>

{
  "documentName": "Invoice.pdf"
}

Response​

{
  "fileId": "string",
  "uploadUrl": "string"
}

The Beneficiary Validation API provides match scores and suggestions to ensure accurate beneficiary field inputs, helping to prevent payment rejections due to invalid beneficiary data. This feature is disabled by default and is available only for limited countries. To enable this feature, please contact us at contact@wallextech.com.

Beneficiary Validation API available for both v2 and v1 API.

Request​

{
  "accountNumber": "string",
  "bicSwift": "string",
  "bankAccountHolderName": "string"
}

Response​

{
  "isAccountFound": "boolean",
  "matchScore": "number",
  "matchScoreDescription": "string",
  "suggestion": {
    "bankAccountHolderName": "string"
  }
}