One payment or every payment
There are two ways to take money from a customer, and the difference between them is not a feature comparison. It is a question about the relationship.
A collection is one request for one amount. A virtual account is a permanent account number that belongs to a customer and accepts payments forever.
The test
Does this customer come back?
If they pay once — an invoice, a checkout, a one-off order — that is a collection. You know the amount, you ask for it, the customer pays, it settles, done.
If they pay repeatedly — a subscription, a wallet they top up, a marketplace seller funding an account — that is a virtual account. They get one account number, they keep it, and every transfer into it credits your balance and creates a deposit transaction.
POST /v1/collections
# one account number, every time
POST /v1/virtual-accounts
Why getting it wrong is expensive
Using a collection where a virtual account belongs is the common mistake, and it does not look like a mistake at first. It works. Every payment succeeds.
What it does is push work onto the customer, once per payment, forever. Every top-up means going back to your app, starting a new payment, getting a different temporary account number, and sending to it before it expires. A returning customer cannot save the details, cannot set up a standing transfer from their bank, and cannot pay you without opening your product first.
That last one is the real cost. A permanent account number means the customer can pay you from their banking app at two in the morning without your product being involved at all. A per-payment temporary account means your app is on the critical path of every single payment.
The reverse error is cheaper but not free: issuing virtual accounts to one-time buyers means collecting identity data you did not need, for a long-lived account nobody will use again.
Identity is per market, not universal
A virtual account belongs to a named person under local banking rules — not to you. So creating one means providing that person's details once, and what is required depends on the currency.
A naira account is verified against the customer's Bank Verification Number and needs a date of birth. A cedi account needs neither. Same endpoint, same response shape, different required fields.
Build the form off the currency rather than off one market's requirements, even when you only support one market today. A single onboarding form with a hardcoded BVN field is a rewrite the moment the second currency arrives, and it is a five-minute decision now versus a migration later.
Reconciliation is the other half of the choice
With a collection you control the amount, so matching is straightforward: you asked for a number, that number arrived, and your own reference travels with it.
With a virtual account you control neither the amount nor the timing. A customer sends what they want, when they want. There is no request to match against — which is exactly why every deposit carries the customer_id the account was created for.
That field is the join. It is the difference between a deposit you can attribute automatically and an unexplained credit somebody has to chase. Set it at creation time and virtual-account reconciliation is a grouping operation; skip it and you are matching on names and amounts, which does not survive two customers called Ada.
They settle the same way
Everything else is shared. Both credit the same dollar balance, both produce a transaction with the same timeline, both fire the same class of webhook, and both settle at confirmation rather than on a schedule.
Which means this is genuinely a product decision rather than a technical trade-off. You are not choosing between fast and slow, or cheap and expensive. You are choosing whether the customer has an ongoing relationship with a balance, and letting the pay-in shape follow from that.
Field tables and currency requirements are in the docs. Questions: hi@spendfigo.com.
Common questions
When should I use a virtual account instead of a collection?
Use a virtual account when the same customer pays you repeatedly — subscriptions, wallet top-ups, marketplace sellers. Use a collection for a single payment of a known amount. The test is whether the customer has an ongoing relationship with a balance.
What is a virtual account in payments?
A permanent bank account number issued to one of your customers. Every transfer into it is credited to your balance and recorded as a deposit, so the customer never has to start a new payment request.
Why do virtual accounts require customer identity data?
Because the account belongs to a named person under local banking rules, not to you. The required fields vary by market, which is why the identity requirement is per-currency rather than universal.