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
Some significant questions for subscription support:
how to handle the async notifications (e.g. success/failure of payment); as these are implemented as service-specific web-hooks, it perhaps makes sense to provide per-gateway Plug.Router implementations that can be used for this with an interface defined for callbacks that must be implemented by the host application (since database access, email generation, service cancellation, etc need to be handled but are all application specific).
should Subscriptions be a new module, or added to the existing gateway interface? My gut feeling is that this should be a new module that uses a gateway, but which provides the various bits of plumbing for Subscriptions. This way, those who do not need Subscriptions can ignore them, and one has a nice separation of concerns between payment mechanics and subscription/recurring payments
The text was updated successfully, but these errors were encountered:
This would be a great addition to the library and I agree this should be a new module that builds on top of the basic gateway interface.
I think this would be a good post v1 release feature, as by that point we will have a stable gateway interface and we will have more time to fully work out the answers to these questions.
I think it would be valuable for us to come up with some client usage scenarios that would help us shape the interface for this module and identify the points of the lifecycle where callbacks would be needed.
Major gateway portals include support for subscriptions, see:
https://developer.paypal.com/docs/classic/use-cases/uc_subscriptions-subscription-payments/
https://stripe.com/docs/subscriptions/quickstart
Some significant questions for subscription support:
how to handle the async notifications (e.g. success/failure of payment); as these are implemented as service-specific web-hooks, it perhaps makes sense to provide per-gateway Plug.Router implementations that can be used for this with an interface defined for callbacks that must be implemented by the host application (since database access, email generation, service cancellation, etc need to be handled but are all application specific).
should Subscriptions be a new module, or added to the existing gateway interface? My gut feeling is that this should be a new module that uses a gateway, but which provides the various bits of plumbing for Subscriptions. This way, those who do not need Subscriptions can ignore them, and one has a nice separation of concerns between payment mechanics and subscription/recurring payments
The text was updated successfully, but these errors were encountered: