Worked reuse example
Virtual account 1234 belongs to order A until Monday 12:00 and to order B from Tuesday 12:00. A transfer is made for A on Monday 11:59, but its webhook arrives Wednesday. The current assignment points to B; the payment record still belongs to A under the stated event-time rule. A payment made Monday 13:00 falls in the gap and needs review. Use invented account numbers in public test data. A real provider may define its own effective-time rule, so record that rule before reuse.
Test the full account life
Follow one virtual account from creation through first assignment, payment, closure, cooling period, and reassignment. Record who owns each period. Send a test transfer with a provider event time from the old period after the new assignment begins.
Checks to run
- Store assignment start and end times with the customer and order IDs.
- Quarantine payments that arrive outside the assigned window instead of guessing the current owner.
- Test late settlement, number recycling, duplicate provider events, and account closure.
Assignment matrix
Test a payment before assignment, during assignment, after closure, and after reassignment. Add a delayed webhook for each. The current owner should receive only payments that the assignment rule links to that owner. An unassigned payment needs a controlled holding path.
Do not expose a virtual account as permanently owned if the provider can recycle it. Publish a clear expiry rule and retain assignment history for the period needed to resolve late funds.
One more boundary test
Test a provider correction to the original transaction time. If the corrected time changes the assignment period, do not move a settled customer credit without a reviewed adjustment. Keep both provider versions and the decision. Also test two webhooks with the same provider reference but different delivery IDs. The deduplication key should represent the underlying payment, not just the message delivery. A virtual account number alone is too weak to decide ownership or uniqueness.
Test a late payment after reassignment
Assign account V-01 to customer A, then deactivate it at 10:00. A transfer with confirmed provider event time 09:59 arrives by webhook at 10:05 after V-01 was assigned to B. A live-assignment-only lookup would credit B. Store the assignment interval and the provider event time, then route the late transfer to a review queue until ownership is clear. Test the same event twice and confirm no second credit. Paystack says a dedicated account is assigned to a customer and bank transfers arrive through webhooks; its API also supports deactivation. Those two actions need one history.
Confirm whether reuse is supported
Treat number reuse as a conditional test for providers that permit it. Dedicated-account creation and deactivation docs do not establish a recycling policy. In the synthetic case, record transfer event time 09:59, assignment A ending at 10:00, assignment B starting at 10:03, and webhook arrival at 10:05. Allocate by the provider’s agreed authoritative timestamp and ownership rule. If the event time is unknown or disputed, hold it for review instead of crediting A or B. A longer cooling period reduces overlap but cannot prove who owns a payment. Keep the provider policy version and both timestamps with the decision.
Primary sources
Next step
Ask your virtual-account provider for its recycling rule, then test a late payment across two assignment periods. Read the related guide. For a review of your own system, request a security review.