Open Hakadel opened 8 years ago
Yeah, this Singleton thing is absolutely appalling. Even if you are working with a single MID, this has odd/scary/dangerous effects. Basically, the way this is implemented right now, it is only safe to make a single request and then destroying the entire environment before making the next request. Pretty much impossible to do anything event based, unit tests, bulk/parallel processing, etc.
Is there any ETA on getting this refactored?
Hi Hakadel,
Does your fork removing the singleton solve the design flaw totally? Seems so simple.. Can't see what it hasn't been implemented in the master if so.
My background is I've been using checkout for a year with no issues for user initiated payments with token or card id.
I tried to run a batch of charges by card id and it got weird. Exceptions for multiple charges but the payments appeared in the hub as captured.
I asked support about it, shared code etc and they advised me to use webhooks. Not really the answer I wanted.. Even more amazing after noticing this has been known for some time. Not cool.
If the fork solves it I'll switch. Appreciate if you can clarify as checkout support hasn't helped.
Many thanks, Phil
Hi Phil,
Yes my fork is working fine, but it's maybe not up to date.
Just remove the singleton implementation because it's useless and everything will be fine.
Best, Benjamin.
Hello guys,
Why are you using the singleton pattern when initializing helpers\AppSetting ?
I'm using Checkout in the same project with multiples MID (so different keys) and because of the singleton it's not working properly.
The lib stores and uses the last configuration so you can't load 2 different classes with Checkout initialized inside, because the keys will be shared.
Thank you.
Best, Benjamin.