I am considering implementing a credits system in my new application. Yes the one I have been constantly posting questions for here.
I am trying to wrap my head around the models and relationships that must be involved. The app allows users to pay for consultations. Consultations have a cost and the cost varies on the options one selects. So lets call that consultation type. Assume bronze, silver, and gold.
So originally I was going to just give each a cost and the user could just stripe pay upon creating the consultation request. But thinking about it more I am starting to like the idea of a credits system. The nature of the app has people likely transacting more than once. So a user would buy credits and then those would be used when they create consultation requests. So structurally....
We have a
App\Consult
model and the consult has a type. My thought was that in order for a Consult to be active, it must have a transaction associated with it. So then we need a
App\Transaction
Consult hasMany Transaction
Transaction belongsToOne Consult
But I am going bugeyed trying to figure out how credits should fit into all this. Credits are not really a model. They are really just a tally of transactions. So there will be transactions that add credits and those that remove credits.
But now the Transaction model stats to get muddy. Can it manage both the storing of new credits as well as the transactions for assigning credits to consultations?
Or do I need whole other entity for this as well? I know this is kind of general but its less about specific code and more about the overall strategy. Would love to hear people's thoughts on this since I found exactly nothing relating to it on these discuss boards.