Get started

The platform account is the account of the Airwallex customer that wishes to implement the PSP-agnostic solution. A platform account is needed in order to use Airwallex’s API. The platform account can onboard marketplaces and sellers. For more information, see Set up your platform account.

A platform Holding Account serves the purpose of holding funds received from PSPs. The funds are distributed from the Holding Account to the different sellers and to the platform itself, whenever the platform chooses.

After the platform sets up a Holding Account, the next step is to set up associated Global Accounts , to which PSPs will send the funds. The platform will provide PSPs with these Global Account details -- note that a separate Global Account should be set up for each PSP/currency combination that the platform anticipates needing. All funds sent by PSPs to these Global Accounts will be deposited into the Holding Account’s multi-currency wallet to await disbursement. Learn more about how a Global Account differs from a Wallet.

The platform will set up a connected account for each of the marketplace’s sellers, to hold any funds received from a settlement, and to fund any refunds/chargebacks that the seller owes. The seller account can never have a negative balance. See Onboarding connected accounts for more details on how to set up connected accounts.

The funds in this account belong to the seller. The platform needs to link each seller account to the seller’s external bank account, in order to process payouts to the seller.

A key benefit of using Airwallex's PSP-agnostic solution is that the sellers are onboarded to Airwallex once as connected accounts but don't need to be onboarded to the acquiring PSPs. The platform/marketplace is the Merchant of Record for acquiring PSPs.

In the marketplace model, all fees distributed to the marketplace can be split to the platform account’s Wallet. This Wallet should therefore be linked to an external bank account for payouts, just as with any seller account. Note: In the case of the MTP model, a separate marketplace fee account should be set up for each marketplace.

A settlement from a PSP will include the net cash balance of all sales (positive) and refunds/chargebacks (negative) across all sellers. Within a settlement, some sellers will be due for a credit split, that is, a “net positive” amount (sales exceeding refunds/chargebacks) transferred from the Holding Account to the seller account, and other sellers may be due for a debit split, that is, a “net negative” amount (refunds/chargebacks exceeding sales), transferred from the seller account to the Holding Account.

This means that sometimes there may not be sufficient funds in the Holding Account to release funds to sellers. This could happen if a platform releases the credit splits to sellers first, before releasing the debit splits from sellers; or if a seller account doesn’t have enough funds to cover a debit. Without adding funds from the debits into the Holding Account, there won’t be enough money to cover all the credits. (See illustration below for more details). As a result, some credit releases to sellers won't be processed.

The Collateral Account solves this problem. By setting up a Collateral Account for each platform Holding Account, if there are insufficient funds in the Holding Account, the Holding Account will be allowed to go negative, as long as there are enough funds in the Collateral Account to cover the shortfall. In this way, the dispersal of funds to sellers will not be blocked. The money that covers a negative Holding Account balance will remain in the Collateral Account, but will be classified as reserved and cannot be withdrawn. Aside from the reserved amount, a platform can add and withdraw funds from a Collateral Account whenever they wish. Note that a negative balance in the Holding Account for each currency must be covered by a separate Collateral Account balance in that same currency.

It is recommended (not required) that the platform stores PSP settlement split information in its own database for internal reconciliation. In this example, each PSP settlement split is stored as a record with status PLANNED before the information is shared with Airwallex, and the status is changed to the one provided by Airwallex after a psp_settlement_split.created webhook notification is received.