The hard part of collecting by bank transfer is not the transfer. It is opening a statement with two hundred credits on it and working out which invoice each one belongs to. A unique account number per customer removes the guessing.
How it works
Create a virtual account number, a virtual UPI ID, or both, tied to a customer in your system. There is no limit imposed by physical account opening.
The customer pays to their own account number, from any bank, by NEFT, RTGS, IMPS or UPI. Nothing changes in how they pay.
Because the destination is unique to that customer, we know who paid without parsing a narration field or matching on amount.
A webhook fires the moment the credit lands, carrying the customer reference, amount, UTR and timestamp. Your ledger updates without anyone opening a statement.
Capabilities
Issue a unique virtual account or UPI ID per customer. Incoming money arrives already attributed, so matching payments to invoices stops being a manual job.
For businesses invoicing repeat customers — lending, education, B2B supply — where the hard part is not collecting money but knowing who sent it.
A unique account number for each payer
Inbound credits matched to the payer on arrival
The same attribution model over UPI
Webhook the moment a credit lands
Statements and custom date-range exports
Separate lines for branches or business units
The usual approach is to ask customers to put an invoice number in the payment narration and then match on it. It works until someone types it wrong, truncates it, pays two invoices in one transfer, or leaves it blank.
At small volumes a person fixes those by hand. At larger volumes the exceptions become the job. Attribution by destination account removes the failure mode rather than managing it.
A customer paying half an invoice, or three invoices in one transfer, is still correctly attributed to that customer. The allocation across invoices stays your decision, made against a credit you already know the source of.
That is a materially easier problem than working out who sent the money in the first place.
Where you operate branches, franchises or business units, virtual accounts can be grouped so each line reports separately while settling to the same underlying account.
Useful when the person who needs the collection report is not the person who needs the consolidated one.
Questions
It is a real, addressable account number that accepts inbound transfers from any bank, mapped to an underlying pooled account. Your customer pays it exactly as they would any other account. It does not hold a separate balance of its own.
Enough to give every customer their own. Issuance is programmatic rather than tied to opening a physical account, so scale is not the constraint it would be with real accounts.
NEFT, RTGS and IMPS to the account number, and UPI to the virtual UPI ID. Your customer chooses.
The credit is attributed to whoever owns that account number, because that is what the banking network was told. You will see it clearly in the ledger and can reallocate it internally, but the attribution itself follows the money.
TrustPay is built so these work together. Money in, money out, and the ledger in between.
Your volume, category, payment methods and settlement cycle. Four answers and you have a rate.