Active Subscription Stripe Status But Expired Account on Live Site

Hello Kyle,

I thank you very much for your torough help and support in trying to resolve this issue 

Thank you also for having letting me know that the webhook is working fine and is reaching CBSubs, this is great news and for having making CBSubs to the latest Stripe API.

Yes, I do have charge.succeeded in the webhook logs as you are describing. 

Another example that I saw yesterday is that someone had their membership renewed successfully on Stripe but there's no IPN notifications on SBSubs about this, no logs on CBSubs about it and the member's expiration date is not up to date, expiring earlier than it should normally be. 

I am sharing with you the webhook logs that I have below in case that might be helpful to understand the issue, if there are things I am not seeing about an issue (I have masked some private information about the member even though it is in the confidentiality bbcode). 


charge.succeeded - Response : 200 (OK) - webhook skipped: nothing to do
payment_intent.succeeded - Response : 200 (OK) - webhook skipped: nothing to do
invoice.payment_succeeded - Response : 200 (OK) - webhook skipped: waiting for charge













I currently have two monthly plan of €22 and €33 and I am sharing with you the config for both of them which are the same, except for the price.


Presentation

 Prepare content using CMS Content plugins : No, do not run CMS {...} triggers

Price display of plan (default: [AUTOMATIC]) : [AUTOMATIC]

Parent plan : Top

Exclusive plan : Exclusive, other plans of same parent cannot be subscribed same time, but one subscription is mandatory

Hide children plans if unselected : No, children plans always visible, if any

Template / CSS

Template for displaying this plan : The template chosen in the global CBSubs Settings


Pricing

 Currency : Euro

Pricing and validity

Is the first amount and period different : Always same period and price

Regular Plan pricing and validity

Regular Price of plan : 33.00000

Regular Validity duration : 1 month

Total number of occurrences of regular validity/price (0=unlimitted) : 0

Prorate remaining value of this plan when upgrading : no

Renewable in advance by : 1 day (24 hours)

Grace period before real expiration : 3 days

Can be reactivated if expired or cancelled since more than : Can be reactivated anytime

Can be reactivated if expired or cancelled since less than : Can be reactivated anytime

Manual renewal extends expiration date as follows : Renewal starts at expiration date or at payment date - whichever happens last (allows free gap)

Auto-recurring renewals (*): User's choice: leave choice to user (*)


Workflows

Selected by default : yes

Registration CB workflows

Allow registration : yes

Propose spontaneously plan at registration : Yes: show automatically plan for normal registrations (recommended)

User Email Confirmation : Default (CB setting)

User Approval by Moderator : Yes, after payment (override CB)


Conditions : --- None (click to add dynamic conditions if needed) ---

Subscriptions upgrades workflows

Allow upgrade to this : yes

Propose plan for upgrades only if it is more expensive : No: It will be possible to upgrade to this plan (for free with pro-rating) if all conditions below and elsewhere are met

Propose spontaneously plan for upgrades : Yes: show automatically plan for normal upgrades (recommended)

Static Conditions on already existing subscriptions and CB Fields and Dates to allow upgrades

First static condition : --- None (click to add static conditions if needed) ---

Dynamic Conditions on other plans to show this plan and to allow upgrading to it

Dynamic Conditions (with Javascript animations) : --- None (click to add dynamic conditions if needed) ---


I also have SQL Actions Integrations to change Kunena Rank when members change their membership like for example "UPDATE `*****_kunena_users` SET `rank` = 12 WHERE `userid` = '[user_id]'".



I also have another question in order to try to mitigate the consequences of this technical issue, if you don't mind. I was trying to manually change member's expiration dates manually so that their access remains while it is not fully resolved and until everything can be managed automatically again.

I went to CBSubs > Subscriptions and then on the right there's the ID. I clicked on the ID and there I can change the expiration, which I did but it doesn't seem to work well as far as what I've seen. Then I saw the warning saying : "A Subscription is automatically created and administered. Don't touch things here, but do it from backend Community Builder User Management in Subscriptions tab please. This pannel is only provided for information, no warranty on effects of changes."

Do you know if this is possible and if this is the way to do it or is there another avenue to make this happen ?


I thank you again for your precious help and patience, hoping this will be resolved soon.

I wish you all the best,
Mathias

Ok, looks like you might be experiencing the same thing I went through. Subscription renewal webhooks don't respect the webhook version the subscription was sent with. There's breaking changes in 2025-04-30.basil version with those webhooks. It makes it impossible for CBSubs to retrieve the invoice of the charge or payment intent for those webhooks as latest_invoice among other things were removed from various Stripe objects. That in turn prevents CBSubs from finding out what subscription those webhooks belong to.

I've been in contact with Stripe the past few days investigating this and have found a suitable workaround. So likely tomorrow we will hopefully have a new build available to fix this. We basically needed to make our webhooks forward compatible all the way up to version 2025-04-30.basil due to future Stripe webhooks not respecting the version the subscription was created with. So this is basically a problem with Stripe, but we'll get this fixed no matter the fault.

Will work as quickly as I can to get CBSubs Stripe upgraded, but there's a lot to go through and hopefully tomorrow will have a build ready to finally fix this.

Hello Kyle,

Thank you so much for sharing all this detailed and precise information about what you found out about this technical problem.

I'm very happy and grateful that you looked into it to find a solution. Thank you so much for your hard work, your invaluable help and for coming up with an update so quickly to fix this. It really is wonderful ! 

In the meantime, I've found the solution of extending the member expiry date manually, which now seems to be working well, greatly limiting the consequences of this technical problem, so there's no urgency on my part.

Do you still need access to my site to see what might be causing this problem? From what I've understood, it seems that you don't, because the reason you suggested it to me, a problem with a menu item, no longer seems to apply. If you still need them, I can share them with you.

I thank you again and wish you lots of luck with all the work you're doing, with all my gratitude.

Mathias

I won't need access to your site at this point as there isn't anything wrong with your site so no worries there. I appreciate your patience during all of this and do apologize this happened to begin with. Hopefully Stripe can fix the webhook versioning bug, but regardless we'll try to stay on top of this more actively.

Ok, this has all been fixed and I've tested every payment scenario. Test Clocks were used to test subscription renewals. Our webhook implementation is backwards and forwards compatible until the next breaking API change I suppose until Stripe fixes webhooks not respecting object API version. Once reviewed and merged we'll have a new CBSubs build release out fixing this.

This is now fixed in latest CBSubs build release. I've completely updated our API usage throughout to latest Stripe API version and improved webhook handling to support latest API changes, while still being backwards compatible with older API versions.