Search...
Log inGet started
Airwallex logo
Home
Core API
Payments
Transactional FX
Payouts
Issuing
Back to home
OverviewHow Airwallex Payouts work
Payout network
Use cases
Transfers
Create a transfer
Transfer statusesGenerate a confirmation letterSimulate transfer status transition
Validate a transferManage transfers
Transfers to countries/regions with capital controls
Create a transfer to an Airwallex account
Embedded Transfer component
Test and go live
Older API versions

Create a transfer

Update: Starting from API version 2024-09-27, the Payment resource has been renamed to Transfer. This change affects all occurrences of "payment" throughout the former Payments API and Webhook events. See more details in this changelog API.

Airwallex Transfers allows you to move funds across the globe easily to your suppliers, employees, contractors and/or own bank accounts. As a platform, you can bring your customers onto Airwallex and enhance your product offering by creating transfers on their behalf. Learn how to programmatically create transfers with our Transfer API endpoints API in the following sections.

Before you begin

  • Obtain your access token API by authenticating to Airwallex using your unique Client ID and API key. You will need the access token to make API calls.
  • Check out Payout Network for supported regions and currencies, and the country guides under it for more details on transfer methods, delivery times, and other country specific details.
  • As a platform, you can call all Transfers API endpoints on behalf of your connected accounts by specifying the connected account's open ID (in the format acct_xxxxxx) in the x-on-behalf-of header of your API request. To learn about how you can register as a platform and set up this solution, see Global Treasury and Global Finance.

Step 1: Prepare required beneficiary information

Before creating a transfer, you will need to prepare the required beneficiary information, which can vary depending on the transfer country/currency, transfer method, local clearing system, beneficiary type.

Our dynamic schema API allows you to obtain precise field requirements specific to the intended transfer scenario. Refer to the screenshot below on which fields you can specify to generate the schema.

Dynamic schema - renamed 2024

The dynamic schema comes in handy when you are checking for a handful of transfer scenarios. To obtain our full schema for beneficiaries programmatically in a JSON payload, you can call Get the API schema API to retrieve the required fields and validation rules, and/or Get the form schema API to retrieve suggested specifications on the UI components to render the fields along with the corresponding validation rules. See Using API and form schemas to learn more.

Furthermore, beneficiary information can be saved beforehand and used directly when creating a transfer by specifying the beneficiary_id instead (see Step 2).

Step 2: Create a transfer

Call Create a new transfer API with the required beneficiary and transaction information (currency, amount, date, reference) to create a transfer.

Beneficiary information can be specified within the request in two ways:

  1. Beneficiary ID

    If you prefer to save beneficiary information with Airwallex in advance to simplify the transfer creation process, you can call Create a new beneficiary API, and a unique beneficiary_id will be returned. This can be used in place of the beneficiary object to create the transfer subsequently.

    See Create beneficiaries and Manage beneficiaries to learn more.

  2. Directly within the request

    If you prefer to manage all beneficiary information outside of Airwallex, you can provide beneficiary information directly under the beneficiary object each time when calling Create a new transfer API.

Refer to the dynamic schema API for precise field requirements specific to the intended transfer scenario. If you specify a parameter that is either not required or not on the full schema, it will be ignored and removed from the response. Please find below further considerations on some of the required parameters:

  • beneficiary: beneficiary details should be provided directly in this object if beneficiary_id is not used:

    • bank_details: Required beneficiary bank account details parameters will vary according to the specified transfer scenario. Please refer to dynamic schema API or call Get the API schema API to obtain the corresponding parameter requirements.
    • address: required address parameters such as street address, city, state and postcode will vary according to the specified address country. Please refer to dynamic schema API or call Get the API schema API to obtain the corresponding parameter requirements.
    • entity_type: Specify whether the beneficiary is an individual (PERSONAL) or a business (COMPANY).

    • company_name, OR first_name and last_name: The beneficiary’s name according to the entity_type.

  • transfer_currency: The currency (3-letter ISO 4217 code) in which the beneficiary receives. It must match account_currency of the beneficiary’s bank account details. See Payout Network for supported currencies.

  • source_currency: The currency (3-letter ISO 4217 code) in which to fund the transfer. If it is different from transfer_currency, an underlying currency conversion will be booked (Refer to Transactional FX for more details).

  • transfer_amount OR source_amount: Please only specify one of these two amounts in their respective currencies. The other amount will be calculated and returned in the response.

Actual amounts with transfer fees applied (if any) are returned as amount_beneficiary_receives and amount_payer_pays in the response. If a transfer was initially created and submitted for approval, these amounts are tentative based on the exchange rate at the time of creation until the transfer status changes to SCHEDULED, at which point the exchange rate is confirmed. By default, transfer fees are charged to the payer i.e. added to transfer_amount and resulted in amount_payer_pays. If you wish to pass on the fees to the beneficiary, you can specify using the fee_paid_by parameter (see below for more details).

  • transfer_method: Specify SWIFT to create an international SWIFT transfer; or LOCAL to create a transfer via the local clearing system, which is faster and more cost-effective. See Payout Network for supported transfer methods by countries/regions and currencies.

  • reference: A user-specified reference that may be displayed to the beneficiary on their bank statement, depending on whether this is supported by the local clearing system and our banking partners. Contact your Account Manager to confirm whether display of reference is supported for your transfer scenarios.

In addition, you may also choose to specify the following optional parameters in your request to further customize the transfer or leverage other related features:

  • beneficiary.additional_info.personal_email: Specify this parameter if you want the beneficiary to receive an email notification upon transfer being dispatched. Please contact your Account Manager to enable this feature beforehand.

  • fee_paid_by: By default, transfer fees will be charged to the PAYER and included in the amount_payer_pays within the response. If you wish to pass on the fees to the beneficiary, set the value to BENEFICIARY.

  • swift_charge_option: By default, SHARED will be applied, in which case the SWIFT charges will be shared between the payer and the beneficiary, i.e. the beneficiary will receive the amount_beneficiary_receives less corresponding SWIFT charges by the beneficiary bank. If you want the beneficiary to receive the full amount_beneficiary_receives, set the value to PAYER to cover the additional SWIFT charges.

  • transfer_date: Specify a current or future date (ISO 8601 format) for when the transfer should be processed. If left blank, the transfer date will default to the earliest possible date and your transfer will be dispatched as soon as possible.

    For transfers with the same source and transfer currency, you can specify a date up to 120 days into the future. For transfers with currency conversions, generally you can specify a date up to 2 days into the future (varies by currency pairs). Longer tenors up to 180 days (varies by currency pair) is possible with our FX forwards product for Australia or Hong Kong customers, but additional regulatory restrictions and application/review process may apply. Please confirm the acceptable value dates by currency pair with your Account Manager.

    For transfers created and submitted for approval, the transfer_date will be updated if it was approved after the original specified date; at which point the transfer status transitions to SCHEDULED and transfer_date is fixed. The date when the transfer is SENT will be returned in dispatch_date.

  • quote_id: Specify the quote_id returned from a previously created quote to fix the conversion rate of the transfer. You must also ensure that the source_currency and transfer_currency in your transfer request match the sell_currency and buy_currency from the quote. By default, the prevailing market rate at the point of conversion (see Rates) will be applied to the underlying currency conversion. See Transactional FX to learn more about the options you have in performing conversions and how you can leverage the corresponding API endpoints. Quotes cannot be applied for creating and submitting a transfer for approval.

  • payer or payer_id: Specify the payer information other than the Airwallex account owner with POBO (Pay On Behalf Of) enabled on a case-by-case approval basis. Similar to beneficiaries, the payer information may be provided directly within the payer object, or by specifying the payer_id of a saved payer. See Create a payer for more information. By default, Airwallex identifies the payer as the Airwallex account owner creating the transfer (connected account owner in a platform use case), and it is not necessary to specify the payer information.

Example request

To create a transfer to a saved beneficiary using beneficiary_id:

Shell

To create a transfer by directly providing beneficiary information:

Shell

If you are registered as a platform account, you can call this endpoint on behalf of your connected accounts by specifying the open ID in the x-on-behalf-of header.

Example response

JSON

Fund deduction

Generally under the pre-funding workflow, funds will be immediately deducted from the Wallet upon transfer creation (including future dated transfers). If a transfer was initially created and submitted for approval, funds will be deducted from the Wallet when the status of the transfer transitions to PROCESSING. Please ensure that you have sufficient balance in your Wallet when creating transfers.

Alternatively under the post-funding workflow, certain customers without sufficient balance are permitted to create transfers in advance, which will be processed once funded automatically or manually:

  • Auto-funding mode: Funds will be deducted from the Wallet on transfer date from 9am, on a first-in first-out basis based on the earliest transfer_date, and the earliest created_at time. Funding will be retried every 30 minutes if wallet balance is insufficient.
  • Manual-funding mode: Transfers will not be processed unless funding instructions are confirmed to be processed on transfer date by calling Confirm funding for a transfer API.

To learn more about fund deduction models, please see Funding and Settlement Models.

Transfer fee

The fee component of a transfer is calculated by Airwallex and communicated back via fee_currency and fee_amount in the API response, while amount_payer_pays and amount_beneficiary_receives represent the actual amounts that you will pay and the recipient will receive respectively (with fees applied). If a transfer was initially created and submitted for approval, fee_amount, amount_payer_pays and amount_beneficiary_receives are tentative based on the exchange rate at the time of creation until the transfer status changes to SCHEDULED, at which point the exchange rate is confirmed.

The transfer fee is set to be paid by the payer by default, while you can pass on the fees to the beneficiary instead by specifying BENEFICIARY for the fee_paid_by parameter in your request. See more details above in the description of request parameters.

Errors

Airwallex uses conventional HTTP response codes API to indicate the success or failure of an API request.

A HTTP 400 status code indicates an error that has been triggered due to the information provided in the request. See Error codes to learn about all possible errors associated with the HTTP 400 status when creating a transfer.

Step 3: Retrieve a transfer

Call Get transfer by ID API or Get list of transfers API to retrieve transfer details. Additionally, you can subscribe to Transfers webhook events to receive any transfer status transitions (the payload will be in the same manner as Create a new transfer API). See Transfer statuses for more information.

Retrieve a list of transfers

Call Get list of transfers API to retrieve details for transfers based on specific conditions.

You can specify the date range of transfer creation (from_created_at and to_created_at, inclusively) whithin the endpoint URL of the request, and the response will be in the same format as in the response of Create a new transfer API. You can also use optional parameters such as transfer_currency and status to filter your transfers, and the pagination parameters (page_num, page_size) to refine the results.

Example request

Shell

If you are registered as a platform account, you can call this endpoint on behalf of your connected accounts by specifying the open ID in the x-on-behalf-of header.

Retrieve details of a transfer

Call Get transfer by ID API to retrieve details of a transfer by specifying the transfer_id.

A successful request will return response in the same format as Create a new transfer API.

Example request

Shell

If you are registered as a platform account, you can call this endpoint on behalf of your connected accounts by specifying the open ID in the x-on-behalf-of header.

On this page