Virtual Accounts

A virtual account (VA) gives your customer bank details for receiving payments into their 1Money balance. Share those details with a payer, who can then send a bank transfer.

For example, a business could use one virtual account for subscriptions and another for wholesale payments. Each has its own receiving details, and both receive funds into the same customer's balance.

Use an existing account or create another

Start with List Virtual Accounts. Your customer may already have a default account, identified by is_default: true, with receiving details ready to use. Default accounts are managed by 1Money.

Create an additional account when the customer needs to keep different payments separate. Additional accounts have is_default: false, and you can name, deactivate, reactivate, or delete them through the API. Creation currently supports USD for eligible customers who have completed identity verification.

Each virtual account has a virtual_account_id that you can store alongside your own records. It may have instructions for more than one payment network, such as ACH and wire. Use the networks returned for that account to decide how the payer can send funds.

Receive a payment

1. Retrieve the virtual account before showing payment details. When status is ACTIVE, choose the payer's network from the returned networks.
2. Give the payer the bank details, beneficiary details, account identifier, and any required memo from that network's instructions. Use account_holder for the beneficiary name, and copy a returned memo exactly.
3. Wait for deposit.completed to confirm that the payment has been credited.
4. Use the webhook's transaction_id to retrieve the transaction. When available, receiving_virtual_account identifies the account that received the payment.

A virtual_account.active webhook tells you the account is ready to receive payments. Track the payment itself through deposit webhooks.

Account status

Only active accounts return receiving instructions. Fetch them when you need to display them, since bank details and availability can change.

If a customer wants to pause using an additional account, deactivate it. If they no longer need it, delete it. Deletion cannot be undone. In either case, stop sharing the bank details first: the bank may still receive transfers already sent, and those funds may need manual review. Reactivating an account does not automatically release payments already held for review.

Monthly fees

The fee object shows the monthly fee for an additional virtual account, in USD.

An additional account incurs one month's usage for each UTC calendar month in which it is active. There is no proration. Deactivating and reactivating it in the same month does not add another month's usage, and receiving payments over several networks does not multiply the fee.

Deleting or deactivating an account does not cancel fees already incurred. Default accounts return fee: null for this additional-account fee. Other account and transaction charges may still apply.

Match a deposit to its VA

When the receiving virtual account can be identified, the transaction includes receiving_virtual_account. Otherwise, this field is null.

For an identified account, the object looks like this:

{
  "virtual_account_id": "VA-7K3M-9X2R",
  "nickname": "Subscriptions",
  "external_id": "550e8400-e29b-41d4-a716-446655440000"
}

Use virtual_account_id to match the payment to your records. The nickname is the account's current label, so renaming an account can change the label shown on older transactions.

Deposit webhooks contain the transaction ID; retrieve the transaction to get this object. A null value does not mean the payment failed. For an auto-conversion, look at the deposit sub-transaction.

If you currently use the deprecated Fiat Deposit Accounts endpoint, follow Migrate to Virtual Accounts.