Stripe manage subscription - invoice.paid and checkout.session.completed

user_4420543 0
Viewed 425

I've seen this similar question, but it did not answer the question asked.

I can't understand how to manage re-occurring subscription.

I did a test and the following events were fired after a successful Stripe Checkout test payment:

  • charge.succeeded
  • checkout.session.completed
  • payment_method.attached
  • invoice.created
  • customer.subscription.created
  • invoice.updated
  • customer.subscription.updated
  • invoice.finalized
  • invoice.paid

My issue is that both checkout.session.completed and invoice.paid is getting fired. I understand that session can be completed in the following cases

  • failure
  • cancel
  • start of a trial
  • successful start

Stripe docs says this:

The minimum event types to monitor:

EVENT NAME DESCRIPTION
checkout.session.completed Sent when a customer clicks the Pay or Subscribe button in Checkout, informing you of a new purchase.
invoice.paid Sent each billing interval when a payment succeeds.
invoice.payment_failed Sent each billing interval if there is an issue with your customer’s payment method.

And in the code part:

For checkout.session.completed:

# You should provision the subscription and save the customer ID to your database.

For invoice.paid:

# Continue to provision the subscription as payments continue to be made.

So then I thought there was surely a way to identify that checkout.session.completed and invoice.paid would be related to each other, but then the problem is that checkout.session.completed does not contain any Invoice id and the invoice.paid does not contain an id for the CheckoutSession where it was created from.

How do I give users only one month of subscription, instead of 2? Does Stripe even keep track of the end of the subscription?

Because in the tracking section here, it says:

  1. ...
  2. Your site receives an invoice.paid event.
  3. Your webhook endpoint finds the customer for whom payment was just made.
  4. Your webhook endpoint updates the customer’s current_period_end timestamp in your database to the appropriate date in the future (plus a day or two for leeway).

So this page ignore the checkout.session.completed endpoint entirely and relies on invoice.paid only, which supposedly may only arrive hours later than the session completed. (I can't find the link on this.)

stripe-payments
1 Answers

My issue is that both checkout.session.completed and invoice.paid is getting fired. I understand that session can be completed in the following cases

  • failure
  • cancel
  • start of a trial
  • successful start

This is not correct. checkout.session.completed only fires when the Checkout Session completes successfully. The documentation in the API reference for checkout.session.completed event says:

Occurs when a Checkout Session has been successfully completed.

I noticed you mentioned this quote from the documentation regarding this event:

Sent when a customer clicks the Pay or Subscribe button in Checkout, informing you of a new purchase.

The keywords there are "informing you of a new purchase"; this event will not fire on failure to pay (i.e. when no purchase has been made). It will be fired on successful creation of a Subscription with a trial though.

So then I thought there was surely a way to identify that checkout.session.completed and invoice.paid would be related to each other, but then the problem is that checkout.session.completed does not contain any Invoice id and the invoice.paid does not contain an id for the CheckoutSession where it was created from.

The Checkout Session will specify the associated Subscription in its subscription property. From there you can look at that Subscription's latest_invoice property to get the latest Invoice ID.

To determine if you should provide whatever goods or services your customer is subscribing to you may want to use the customer.subscription.updated event. This will give you updates about changes to the status of the Subscription, and you can provision based on that status. For example, if the status is trialing or active give them access, but if it's anything else don't give them access.

user_10765620
Related