Add monthly subscriptions

[jorgemanrubia]

https://3.basecamp.com/2914079/buckets/37331921/todos/9346492118

See basecamp/fizzy#2050

[jorgemanrubia]

This is a simple admin screen where you can modify the card count in a given account. It is intended mostly to test this in staging.

[jorgemanrubia]

Moved to the gem, but unrelated to the billing system.

[jorgemanrubia]

Hey @zachasme I would love your eyes on how we are handling stripe webhooks and on the flow in general.

[zachasme]

Looks great @jorgemanrubia!

I only see one potential issue that have bitten me in the past: Stripe doesn’t guarantee the delivery of events in the order that they’re generated (WTF?). If I recall correctly, a successful checkout session will generate:

• checkout.session.completed
• customer.subscription.created
• customer.subscription.updated

almost always in that order. Additionally, event data will correspond to the time it was dispatched, so if you handle created after updated you could end up in a bad state.

I have found the best solution is not to rely on any data provided in event payloads, except identifiers. I would recommended something like:

when "checkout.session.completed"
  sync_subscription(event.data.object.subscription) if event.data.object.mode == "subscription"
when "customer.subscription.updated"
when "customer.subscription.deleted"
  sync_subscription(event.data.object.id)

#...

def sync_subscription(stripe_id)
  stripe_subscription = Stripe::Subscription.retrieve(stripe_id)
  if subscription = find_subscription_by_customer(stripe_subscription.customer)
    cancellation_reason = stripe_subscription.cancellation_details.reason
    subscription.update! #...
  end
end

I also think stripe dispatches customer.subscription.deleted when payment fails, in which case you can use stripe_subscription.cancellation_details.reason instead of listening for invoice.payment_failed.

[jorgemanrubia]

Thanks @zachasme, super useful, I will tackle this tomorrow.

[jorgemanrubia]

Hey @zachasme could you have a second look at the changes 🙏?

[zachasme]

I still think there's going to be an issue if checkout.session.completed comes in last, since the subscription plan_key is being validated for presence. I'd try and stick to calling sync_subscription directly from all branches, and read the plan_key from subscription metadata in all cases.

[zachasme]

Oh, the subscription is already created with a plan_key before checkout, so probably not an issue. But generally I still think we should avoid branching logic based on event type.

[kevinmcconnell]

@jorgemanrubia curious if you looked at using op run for handling the secrets, rather than Kamal?

It ought to take care of some of these details for you, and would let you move the secret & env names into a file like .stripe-env rather than have them inside the script. Then you could exec both the stripe listen and bin/dev with the necessary secrets in place.

[jorgemanrubia]

@kevinmcconnell thanks, that would be an improvement indeed. I will track this one in Basecamp, as I want to finish up other stuff this week first.