I'm building a walled-garden e-commerce system where many users will add funds to the system. They can then spend these funds with merchants, who can then cash them out from their virtual account to real money in their bank account.
Due to implementaion details with our payment provider, every time a user pays in they create a new unique user entity within the payment provider.
When a purchase is made, funds are transferred from these users' accounts into the merchant's account (one per merchant, merchant's are fully qualified citizens with our payment provider).
The merchants can then cash out, where funds will be transferred out of our system and into their highstreet bank account.
The questions I'm asking myself are how do I structure those P&L accounts for the payments into the system and the payments out of the system? What I've read about double entry book keeping suggests that each cateogry should be represented by an account, so one for payments in, and one for merchant withdrawals, but I'm wondering if this is potentially due to the historically paper based nature of accounting or if it's just not necessary to have any finer detail.
The developer in me wants each payment to come in from it's own account, which would obviously create many (thousands) of accounts with only a single transaction.
The developer in me also wants each merchant to have their own Withdrawal P&L account (with 10s or 100s of transactions).
Obviously I could do it with one P&L for all payments in and one P&L for all withdrawals, and filter and group by the merchants account IDs to find, say the total withdrawal for merchant #1234.
I'm torn, is there a usual (standard, accpeted) way of doing this? Is the granularity worth the overhead?