You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Dynamic payment processors in addition to Stripe Connect
#224
I am in need of paid bookings functionality, but am historically tied to a local payment gateway provider. Their flow is the same redirect flow with a callback as Stripe Connect.
I think a good first approach would be to put payment processing behind what's called an interface in Java world (forgive me for my lack of Go knowledge, I'm a Java dev) and make each gw provider extend that interface. I don't think a fully fledged plugin system dynamic (un-)loading is required or even reasonable. I'd be happy with the implementing classes living directly in the source code, as most integrations would be nearly write-and-forget type endeavors, anyway.
Unstructured thoughts:
I'd love if writing the integration took as few files as possible, in contrast to the steaming heap that is cal.diy;
There might be need to keep track of the gw implementations in the db as a booking entity needs to keep track of which gateway it should use;
A gateway should be selectable per event-type, but configured by admin site-wide;
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
I am in need of paid bookings functionality, but am historically tied to a local payment gateway provider. Their flow is the same redirect flow with a callback as Stripe Connect.
I think a good first approach would be to put payment processing behind what's called an
interfacein Java world (forgive me for my lack of Go knowledge, I'm a Java dev) and make each gw provider extend that interface. I don't think a fully fledged plugin system dynamic (un-)loading is required or even reasonable. I'd be happy with the implementing classes living directly in the source code, as most integrations would be nearly write-and-forget type endeavors, anyway.Unstructured thoughts:
cal.diy;All reactions