Open mjallday opened 10 years ago
A little bit new thinking about how this should go. I think merely running Billy with dummy processor cannot allow us to spot some real issues in real life battlefield. So, I think, maybe we should add a step before the last one - which is to let Billy really charge a partition of invoice, say, 1% or something like that.
We can apply a hash on the event ID, like
SHA1(Event ID) < specific number
if this goes true, then we let Billy process it, if is is not, Balanced API processes it. In this way, we can have real battlefield experience for Billy, and still, if anything goes wrong, there is only little amount need to be recovered, can be done manually with a simple script, shouldn't be a big problem thought.
@victorlin can you elaborate why we shouldn't use a dummy processor? why can't we use a test marketplace to issue bank account debits?
@mahmoudimus We can, but I think there will be some issues in corner cannot be spotted then, the feeling is just like, you do something in a lab, everything goes fine, but when it comes out to the real environment, boom!
By doing that, is just to make sure when we switch the loading to Billy, it is more solid.
@victorlin the test / production code runs exactly the same and goes all the way down the processor so there's nothing to worry about.
But yes, I understand your concern.
@mahmoudimus Well, great, then current steps to migrate will do :)
Once invoicing is implemented the best way to ensure that this code works as required will be to get Balanced to use it for production invoicing of marketplace fees.
A 3-step approach would be best
We have an internal discussion at Balanced on how to implement step 1.
It's unclear how Billy will handle invoice adjustments right now but once that is understood we can begin generate the invoices in Billy.