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
The most straightforward use case for a subscription is to have subscriber-only features, for which pay does all the heavy lifting of processing webhooks and creating objects, and just checking if the user is .subscribed? before any relevant actions is enough.
However, some other use cases require additional logic, like doing some initial setup (for example, giving users access to external resources), monthly fulfillments (like topping up credits), and removing access to resources when the subscription is cancelled.
I initially thought of doing this by adding custom webhook listeners as described in the docs, but I also came across this other idea of adding model concerns to Pay::Subscription and/or Pay::Charge, and then just adding ActiveRecord callbacks that implement this additional logic, like this:
The ActiveRecord callbacks solution looks somewhat cleaner, since it's a processor-agnostic solution and I'm not dealing with or unnecesarily exposing Stripe-specific event names etc. The setup / refill / cleanup gets done only when the ActiveRecord object is created / changes status, and I don't care what specific events get sent to my endpoint.
What's the best practice here? Is there any reason to choose one approach over the other?
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
-
The most straightforward use case for a subscription is to have subscriber-only features, for which
pay
does all the heavy lifting of processing webhooks and creating objects, and just checking if the user is.subscribed?
before any relevant actions is enough.However, some other use cases require additional logic, like doing some initial setup (for example, giving users access to external resources), monthly fulfillments (like topping up credits), and removing access to resources when the subscription is cancelled.
I initially thought of doing this by adding custom webhook listeners as described in the docs, but I also came across this other idea of adding model concerns to
Pay::Subscription
and/orPay::Charge
, and then just adding ActiveRecord callbacks that implement this additional logic, like this:With the corresponding configuration in
pay.rb
:The ActiveRecord callbacks solution looks somewhat cleaner, since it's a processor-agnostic solution and I'm not dealing with or unnecesarily exposing Stripe-specific event names etc. The setup / refill / cleanup gets done only when the ActiveRecord object is created / changes status, and I don't care what specific events get sent to my endpoint.
What's the best practice here? Is there any reason to choose one approach over the other?
Beta Was this translation helpful? Give feedback.
All reactions