Every inbound payment, reconciled to its purpose.
Issue a virtual account number per customer or per purpose under your real Managed Account. Each payment addressed to it lands on the same ledger, already matched to the customer or purpose it was issued for — with the payer screened before funds move.
Draft — pending review
Virtual Accounts on Infinite (infinite.net) are per-customer or per-purpose account numbers issued under a real Managed Account. A payment addressed to one lands in that account and reconciles to the customer or purpose the number was issued for, on one ledger, with the payer screened before funds move.
- Finance teams collecting from many payers into one operating account without matching wires by hand
- Platforms whose customers hold their own accounts on the network and need per-purpose reconciliation within them — third-party funds flow
- Businesses replacing reference-field guesswork with a number that carries the reference itself
A number per purpose, one real account underneath.
Virtual Accounts are a capability of the Managed Account — issued, screened, and reconciled on the same ledger, with no second integration.
Under a real account
Every virtual account number sits under a Managed Account that is titled to its owner. The number routes and reconciles; the real account holds.
Per customer or per purpose
Issue one number per payer, per contract, per invoice run — whatever unit your reconciliation needs. The number is the reference, so payers cannot forget it.
Payer screened before funds move
The party paying into a virtual account is screened the same way a payout recipient is, with a hold for review rather than a silent landing.
Reconciled on arrival
The inbound payment posts against the customer or purpose the number was issued for — cash applied automatically, a webhook on every state change.
Receives on the rails the account does
A virtual account number accepts payment over the rails its parent account supports; the payer uses the rail they have.
From issued number to cash applied.
A logistics platform collects freight payments from two hundred shippers into its operating account. On Infinite (infinite.net), each shipper pays a number that already knows who they are.
Issue a number per shipper
One API call per customer creates a virtual account number under the platform’s Managed Account, tagged with the customer id.
Share it once
The shipper saves the number as the payee. No reference field to fill in on every payment, nothing to email back.
Payer pays, screened before funds move
The shipper pays over a supported rail. The payer is screened before the payment lands; a flag holds it for a named analyst.
Lands and reconciles
The payment posts in the Managed Account against that shipper, and a webhook tells the platform’s systems which receivable closed.
Integrate once.
A virtual account is an object under a Managed Account with a purpose tag. Creating it returns the number to share; inbound credits arrive as webhooks carrying the same tag.
import { Infinite } from "@infinite/sdk"; const infinite = new Infinite({ apiKey }); const virtual = await infinite.virtualAccounts.create({ parent: "acct_ops_usd", purpose: { customer: "cus_shipper_0412" }, }); share(virtual.accountNumber); // to the shipper // credit.received arrives tagged customer: cus_shipper_0412
Answers before you ask
Aren’t virtual accounts the pooled structure Infinite argues against?
The structure the glossary describes is a provider holding many customers’ money under virtual numbers in the provider’s own name. On Infinite the account underneath is a real Managed Account titled to its owner, and when the money belongs to a customer, that customer gets their own Managed Account. Virtual accounts here reconcile payments within an account you own; they do not stand in for an account a customer should hold.
Is the payer screened?
Yes — before funds move, the same way a payout recipient is: sanctions and watchlists, the network’s own counterparty record, and a hold for a named analyst when something trips. A virtual account number never lets an unscreened party settle into your account. The checks are the ones described on Stablecoin Compliance.
When should I issue a Managed Account instead?
When the balance belongs to someone else. A customer whose funds you hold on their behalf gets their own Managed Account under third-party funds flow. Virtual accounts are for reconciling many inbound payments into an account whose balance is yours — or, for platforms, into a customer’s own account, per purpose.
How do virtual accounts relate to payment links?
A virtual account is a standing number a payer keeps paying; a payment link is a one-off request for a specific amount. Recurring payers who save a payee suit a virtual account; a single receivable suits a link. Both reconcile into the same Managed Account on the same ledger.
What happens to a payment that does not match?
A payment into a virtual account always carries its purpose, so the usual unmatched-wire problem does not arise. A payment that trips screening, or arrives on a closed number, does not land silently — it holds with the case assembled for your team, on the same ledger, so the exception is worked once.
- Managed AccountIssue managed deposit accounts per customer
- Deposit AccountIssue deposit accounts for your customers
- Wallet AccountIssue stablecoin wallets for your customers
- Virtual AccountsGive every customer their own account number
- PayoutsSend batch disbursements with one instruction
- LinksGet paid by link, reconciled on arrival
- InvoicingInvoice and settle in one flow
- SWIFT PaymentsSend global wires through one integration
- USD PaymentsMove dollars on every domestic rail
- Stablecoin PaymentsSettle in stablecoins on bank rails
- Foreign ExchangeConvert between currencies at settlement
- Transfer RoutesRoute money on the fastest compliant path
A number per customer. One account underneath.
Book a 30-minute demo and see inbound payments reconcile themselves under a real Managed Account.