Airwallex: business accounts, FX and embedded payment infrastructure

Airwallex provides business accounts, currency conversion, payment acceptance, payouts and spending tools, alongside APIs that embed these functions inside another company’s product. Corporate treasury teams can use its web application to manage their own money; fintechs, marketplaces and software platforms can build customer-facing account and payment workflows. Its platform catalogue separates Connected Accounts, Accounts, Payments, Transactional FX, Payouts and Issuing, with prebuilt components and custom API delivery.[1]

A full connected account has its own wallet, transaction history and enabled capabilities under the platform relationship. The platform can perform authorised operations for that account using its account identifier in the x-on-behalf-of header. This separation matters when mapping customer balances, transaction ownership and reconciliation: a platform’s master account and its customers’ connected accounts are different operational records. Sellers that are the merchant of record need the relevant connected-account setup.[3]

For UK treasury customers, the terms describe physically deliverable FX forwards executed as principal on an execution-only basis. The agreed prepayment and remaining funding obligation are part of the transaction. A failure to fund by the required cutoff can lead to cancellation and an unwind charge reflecting currency movements. This contractual FX service supports currency delivery; investment advice is outside the stated service.[13]

The payout API uses a Client ID and API key to obtain an access token. Beneficiary requirements vary with country, currency, payment method, rail and entity type, so implementations need the dynamic beneficiary schema rather than one universal bank-details form. The documentation also distinguishes API versions: from 2024-09-27, the Payment resource and associated webhook naming became Transfer. Scheduling has a further operational distinction: omitting transfer_date requests dispatch as soon as possible, while explicitly supplying today’s date invokes scheduled-transfer logic. A different source and transfer currency can also require an underlying FX conversion.[6]

The developer terms require authority to act for the customer and protection of credentials and tokens. Tokens must be encrypted and removed when the connection is no longer needed. Security incidents require immediate notice, with an outer limit of 72 hours after awareness. Developers must implement API updates within a reasonable period and no later than six months, and Airwallex can enforce request or concurrency limits. These conditions make credential rotation, account attribution, release management and controlled retries part of operating the integration.[15]

Airwallex publishes UK business-plan prices, while Platform APIs, Embedded Finance and higher-volume arrangements use custom pricing. Published figures below exclude VAT and are a UK example.[11]

Explore’s waiver requires £10,000 of qualifying monthly inflows through bank deposits, direct debits or payment processing, or £10,000 combined wallet balance at the end of the subscription period. The billing unit is the legal entity, rather than each separate account.[11]

The UK-incorporated customer fee schedule was updated on 18 September and became effective on 17 October 2026. Selected charges are below; negotiated terms can define the agreed arrangement.[12]

Plan upgrades take effect immediately; downgrades take effect after the current billing cycle.[12]

Connected-account deployment starts with the customer and funds-flow model, followed by the required information collection, verification, account capabilities and monitoring. Airwallex’s compliance documentation covers obligations before go-live and during the relationship, but explicitly says that it is not exhaustive and does not replace or amend the outsourcing agreement or master services agreement. The practical implementation therefore needs an agreed allocation of onboarding, ongoing monitoring, information requests and customer-facing disclosures alongside the technical build.[4]

For the documented future-dated process, settlement actions occur at 09:00 in the account entity’s time zone, with the bought currency following the required sell-currency deduction. Currency holidays affect available dates. Insufficient postfund balances can incur fees; the documented retry process does not remove the obligation to fund on time.[7]

The FX checklist calls for agreed currencies, transaction limits, value dates and funding settings in the sandbox, followed by conversion, payout, report and webhook checks. Those configuration defaults are examples for the test environment. Production requires its own credentials for each account, production API addresses and separately configured reporting and webhook endpoints. A successful sandbox conversion alone therefore does not establish the live account’s funding mode, approved limits or operational notification path.[8]

For payouts, the checklist includes simulated transfer-status transitions, webhook receipt, reports and confirmation letters. Airwallex strongly recommends production IP whitelisting for platforms. These are useful acceptance criteria for the integration owner: reconcile the customer instruction, API response, subsequent status event and final accounting record, including failed and returned transfers.[9]

The separate Plum case study describes a custom API build and integration with US clearing brokers across fully disclosed, omnibus and self-clearing models. The useful distinction is the role Airwallex performs in that chain: funding and conversion connect to the broker’s stock workflow. The case does not establish that Airwallex itself executes or clears the securities trade, or that every brokerage business is eligible for the same arrangement.[28]

Existing customers are directed to personalised support inside the Airwallex application. The public Help Centre also provides a request route for people who cannot log in. Support scope should be linked to the actual customer agreement, product and account relationship.[24]

For UK complaints, the published process targets acknowledgement within two business days and a final response within 15 business days, extending to 35 in exceptional circumstances. A complaint can be submitted through the form or published support email. Other regions have different timeframes and external dispute routes; the serving entity on the account documentation is relevant to the applicable process.[25]

The default API developer terms do not oblige Airwallex to provide support, maintenance or new releases. A production platform therefore needs its required response coverage, incident escalation and service commitments in the applicable commercial agreement. The existence of a public status site does not itself establish an uptime commitment or a staffed response time.[15][26]

Airwallex’s Acceptable Use Policy requires prior approval for financial-services activities, including trading, investment or fund management, currency exchange and handling funds for other parties. It prohibits unlicensed regulated activity and separately lists foreign-exchange speculation, investment and arbitrage among prohibited uses. A financial firm therefore needs approval for its precise business and money flow; a generic account application or an existing customer case is insufficient evidence of eligibility. The policy also allows restrictions arising from Airwallex’s own risk appetite and that of its banking and payment-network partners.[35]

For UK wallet funds, Airwallex describes safeguarding separately from its operating money and says it is not a bank. It also says the wallet is not protected by the FSCS against Airwallex’s own insolvency, and that insolvency-practitioner costs can reduce the funds returned. Safeguarding should consequently be assessed through the particular account entity and terms. It should not be treated as an ordinary bank deposit guarantee or extended automatically to separate investment products.[21]

On 22 January 2026, AUSTRAC ordered an external audit of the Australian Airwallex Designated Business Group over suspected AML/CTF compliance failures. The stated areas included its programme, ongoing customer due diligence and suspicious-matter reporting. This was an audit order rather than a final finding. Airwallex’s same-day response said it would cooperate fully. The official material reviewed did not establish a later final outcome, so neither a concluded breach nor regulatory clearance is asserted here.[22][23]

Airwallex was founded in Melbourne in 2015. Its expansion now includes accounting and financial-data software as well as financial services: the June 2026 Leapfin acquisition added revenue-recognition and reconciliation capabilities. The relevant supplier and agreement still depend on the product and customer jurisdiction.[33]

The company’s regional directory also names Yunhui Pay Co., Ltd. in China, UniCard Solution Limited within the Hong Kong group, Airwallex Lithuania UAB, MexPago in Mexico, Paynuri in Korea and PT Skye Sab Indonesia. These names matter when reconciling contracts, account statements and acquired brands. The directory is a group map, not evidence that one subsidiary’s licence or investment permission applies to all the others.[17]

Operator

Regional Airwallex group entities, including Airwallex (UK) Limited, Airwallex (Netherlands) B.V. and Airwallex (Singapore) Pte. Ltd.

Service scope

Business and embedded account, payment acceptance, payout, FX, issuing, spending and financial-software workflows for accepted commercial customers.

Customer types

Corporate treasury teams; Fintechs and approved financial-services firms; Marketplaces; SaaS platforms; Merchants; Businesses managing international payments and spending

Delivery

SaaS; API; Hosted

Pricing publication

Public and quoted pricing

Platforms

Airwallex Business Accounts; Connected Accounts; Transactional FX; Payouts; Payments; Issuing; Spend; Billing; Leapfin; T:0

Integrations

REST APIs; Embedded components; Hosted onboarding; Webhooks; NetSuite; Connected-account x-on-behalf-of operations

Pricing scope

Public UK business plans and selected transaction fees; platform/API and larger arrangements use custom terms. Charges depend on entity, product and activity.

Implementation

Choose account and funds-flow models, complete onboarding and agreed compliance allocation, configure funding/limits, and establish separate production credentials, webhooks and reconciliation.

Support

In-app support, public Help Centre request route, support email, regional complaints process and component status site. Default developer terms are not a production SLA.

Permissions and regulatory scope

DNB and MAS records match selected electronic-money/payment entities. UK contractual EMI status is explicitly attributed; serving entity, approved activity and product determine the relevant scope.

Provider metadata checked 20 Oct 2026Source 1Source 2Source 3Source 5Source 16Source 11Source 12Source 8Source 4Source 24Source 15Source 26Source 18Source 19Source 13Source 30Source 17Source 35Source 29Source 33Source 34Source 32Source 31

Payment acceptance creates ongoing settlement obligations. The UK Payments Terms use net settlement by default, after applicable fees, refunds, chargebacks, reserves and other deductions. Gross fee settlement requires a written agreement and changes fee collection, while other deductions can continue. Airwallex can impose percentage or fixed reserves and withhold settlement where the contractual risk conditions apply; withheld money is not immediately available for withdrawal or refunds. Reserve release does not extinguish merchant liabilities, and accounts must remain available for later adjustments. A merchant’s operating cash forecast therefore needs to account for the agreed settlement cycle, deductions and reserve conditions.[14]

Under the reviewed UK treasury terms, a customer can terminate with 30 days’ written notice. Outstanding debts remain payable and the customer must withdraw the remaining balance; the terms provide for return to the last UK bank account if funds are not withdrawn. Account closure therefore needs coordinated settlement of open obligations and a usable repayment destination.[13]

The SaaS terms place responsibility on the customer for input accuracy and configuration, including prices, retries, reminders and tax settings. A billing deployment needs those rules checked against the intended customer contracts and accounting treatment. Preview or beta features can be withdrawn and sit outside the stated service-level treatment. This is particularly relevant where a finance team is using software calculations to populate invoices or downstream records: the configured output still needs to reflect the business’s actual obligations.[16]

Stablecoin payouts are explicitly marked early access with limited functionality. The reviewed guide describes an API-only USDC route on Ethereum, with account-manager enablement and configuration. Normal transfer approval still applies; SENT means submission on-chain, while PAID indicates confirmed delivery. Correct wallet and network details are material because an incorrect destination can cause irreversible loss. The standard sandbox simulation does not support this flow; the documentation directs users to an enabled demonstration environment through their account manager. This is a restricted product stage, not general availability across all Airwallex accounts.[10]