Stripe Gateway Handling

Ok, so there isn't really a problem with the integration then. The user failed to comply with 3D Secure. If that was an older payment it probably wasn't using the newer implementation where we added add_invoice_items usage for the initial payments. Are newer payments still doing the $0 invoice?

Ok, have investigated further into why we've implemented it this way. The reason is we can't create a subscription through a PaymentIntent. We have to create it after the fact. So the PaymentIntent handles the initial payment. We then defer the subscription to its next renewal cycle using the start date. If we could create a subscription with the PaymentIntent that'd be preferred.

Additionally have found the emails where I directly contacted them about all of this and implemented as per their instructions. So unless things have changed and we don't need to create subscriptions as separate processes there's nothing I can do about the $0 invoice and if it's not causing any actual problems then it's likely not worth being concerned about.

It does appear they have modelled a process for doing this differently though. Appears they want the subscription created first then have the subscription create the payment intent.

stripe.com/docs/billing/subscriptions/build-subscriptions?ui=elements#how-to-model-it-on-stripe

Will add a feature ticket to moving over to this in a future release, but current implementation should continue to work fine.

forge.joomlapolis.com/issues/9108

Thank you for looking into this in depth, you are correct, they prefer it different than it is now. I did expressly let them know that you guys would have followed their documentation. This is why they sent me all the details to provide you guys.

Unfortunately, this did cause an issue because it didn't create the subscription etc... so the user's next payment was captured but expired their subscription on our end because it never existed on Stripe's side

The security measure you're referring to was not when they initially signed up with us, it was after the issue occurred & then I had to ask them to resignup (never ideal for customers). During their re-signup, this is when the security measure apparently caused an issue. I found this to be ironic because the initial registration didn't have this problem.

So in addition to handling the subscription ordering, would you please make sure the security measures are in place (if not already). This one is specific to India apparently. Thank you!

We don't handle the 3D Secure. Stripe does that during checkout. They'd have to authorize the 3D Secure payment. During payment this should be a popup of some kind in the middle of the page if their bank requires any authorization steps. The current payment process we're doing shouldn't imped this at all, but due to SCA requirements in India it can sometimes cause a payment to be rejected.

Will review redoing our current implementation in a future release, but I don't really have the time to completely rewrite recurring payments behavior at this moment. Their changes to how subscriptions can be made were implemented after our implementation so we'd of course gone that route had it existed at the time.

Ok, it would be appreciated if this was prioritized, especially given the fact that it has already caused issues and we have not been able to recapture that next payment, thus losing funds.
I understand your situation more than you know, however when items cause financial issues, it is a top priority!
Thank you

I'll finish my current tasks (finishing the new layout feature in CB) then review making improvements to CBSubs Stripe, which likely won't be until sometime next week. I've already made an internal note to prioritize this as soon as current tasks are complete.

For now consider switching to Stripe Checkout (hosted payments) to push the responsibility entirely on Stripe and see if that helps with dealing with those payments.