Fixed Stripe Payments - Strangeness with Subscriptions

[goobernacular]

Affected version

2.0.5

I've attached an image to illustrate the problem.

The timeline goes like this:

• Customer creates subscription
• Xenforo creates a "trial period" of 1 minute (I think)
• The initial charge goes through before the trial ends
• The first invoice for $0.00 as a trial is successful
• But the next invoice is immediately generated for the subscription price
• This invoice is not completed and paid because the payment was already processed
• Stripe starts trying to re-create the payment every day or however it's set up, but the bank blocks it

So currently I have this customer (first on the new Stripe API through Xenforo and not the BDpaygate plugin) has an open invoice for the first month that's already been paid before the invoice is generated. It's been trying to re-ping that payment and failing and ultimately I think will cancel the subscription (I'm not there yet, probably tomorrow).

So either it's going to cancel the subscription after 3 fails at a 2nd "back-to-back payment" or it's going to ignore the first invoice and wait a month and charge successfully on the 2nd one.

This doesn't seem remotely ideal. I never set up a trial period or anything in the dashboard.

Can anyone give any insight into this? Is it a bug?

 

[goobernacular]

Possibly related: I have my webhook for Stripe as: .com/stripe_callback.php which seems to be working. I couldn't find information about what to use originally and found that in some discussion, but I did just come across this: .com/payment_callback.php?_xfProvider=stripe on another thread (and now see it on the payment profile page too). The stripe dashboard isn't indicating that my webhook isn't working, and it's definitely sending information back to my forum. I've updated it to the correct callback. Can anyone comment on this as well?

 

[goobernacular]

Actually, this is the 2nd new customer since I updated to Xenforo's new native Stripe processor. The first one went over perfectly even with the incorrect stripe_callback.php webhook. What could have led to this inconsistent behavior?

 

[Chris D]

I’m not sure but certainly you should be using payment_callback.php.

Switch to that and let us know if the problems continue.

 

[goobernacular]

@Chris D, I switched to the correct webhook and got a new subscriber and the exact same thing happened. It generated a minute long trial and then opened the subscription which was already paid, and will now start trying to collect a 2nd payment.

The implications are that the subscriptions are no longer subscriptions since you have to kill the 2nd (legitimate) invoice that should be marked paid, but it's not marked paid because the free trial gets marked paid instead. So once you close that 2nd invoice that tries to recollect again, I think that ends the subscription. It also renders any other finance tracking useless because it doesn't recognize the payment as Monthly Recurring Revenue, but as a one-time payment.

Correction, it does look like you can cancel that invoice and Stripe keeps the "upcoming invoice" for the next pay period. However, this requires manual intervention for each customer and isn't ideal at all, and it still marks the first month as one-time cash flow and not recurring income.

 

[goobernacular]

Is anyone else seeing this behavior? Can the developers look into it and see why this is occuring?

I had BDpaygates or whatever its called on XF 1 but it was disabled when I upgraded to XF 2 and is completely out of use now.

 

[goobernacular]

Switch to that and let us know if the problems continue.

The problems are still here, as described in post #5 of this thread. Any chance this can get looked at? I'd call this a medium sized bug / issue, because it's not critical for everyone but for those of us using the included Stripe payment processor it's critical and causing a lot of manual intervention and ruining performance indicator data dependent on Stripe.

 

[Chris D]

Even if it were looked at fairly soon, we're not due to do another release for at least the next 4 weeks, so that's unlikely to help.

We'll provide more information or a workaround when we start working towards that release. I'll try and hurry that on for you, but I don't have an ETA at this moment.

 

[Chris D]

I didn't want to leave you totally high and dry.

This version is pretty much the same as XF 2.0.4 before we made a bunch of changes to support Stripe's new API. I think the approach we took from 2.0.5 onwards which has caused you these issues has kind of exposed the inflexibility of their recent API changes, but we'll take a look.

For now, this version forces the use of their old API and still uses our pre-2.0.5 approach.

Just download this and replace the file in this location: src/XF/Payment/Stripe.php.

You will get reports of unexpected file contents - just ignore these.

 

[goobernacular]

I didn't want to leave you totally high and dry.

Thank you a ton for your work on this. I want to confirm that everything went exactly as you stated, with the unexpected file contents notice, etc.

I got a new subscription customer since then and it worked perfectly. There were no weird 1 second trials or off-timed payments. It worked as expected. Whatever you did will make a great lead for your team when you investigate this issue. I hope it makes it into the next update!

 

[Chris D]

Unfortunately, all I did was reverse the significant amount of work we put in to support the changes in Stripe's API. You're now essentially using code from 2.0.4 with all that work done in 2.0.5 essentially going to waste, so hopefully that won't be the final solution; not to mention that we need to ensure ongoing compatibility with Stripe's API - although we're forcing a specific Stripe API version here, we can't rely on that being available forever.

When we get closer to a better solution, I'll let you know if that's ok then you'll hopefully have the opportunity to test it works as expected.

 

[goobernacular]

When we get closer to a better solution, I'll let you know if that's ok then you'll hopefully have the opportunity to test it works as expected.

Yes, please do. I understand you have a million things on your plate. When you & the team get the chance, I'll be ready. I appreciate the effort you've already put forth for me.

 

[Chris D]

The version of the code you're using now is what we're rolling with going forward. We'll consider larger changes in the future.

 

[anit77]

The version of the code you're using now is what we're rolling with going forward. We'll consider larger changes in the future.

Hi, just wondering if this was still in the cue for a future update?

We recently switched over to XF from WP and our Stripe acct doesn't have the ability to roll back the api to a version compatible with the file you linked above. We've shut down Stripe as a payment method while we wait.

Thanks

 

[Chris D]

We explicitly set the api version so their API should honour it.

 

[Chris D]

@thehobbster we are looking to re-introduce the new(ish) Stripe Billing API in an upcoming version, hopefully XF 2.1.1.

This is what initially caused this bug report, but I believe we might have solved that issue. I have enabled XenForo 2.1.1 Beta 2 on your customer account so you can do a one-click upgrade in your Admin CP or just download that from your customer area.

The trial behaviour should now work correctly, and therefore you shouldn't experience the same problems with them as before.

 

[goobernacular]

@Chris D , thank you for the update. I'll test this ASAP and give you as much feedback as I can.