Subscription Payments Failed for Enterprise

[lin-d-hop]

Description

We have one enterprise for whom subscription payments have been failing since the end of April.

On investigation I found that they had change the length of their order cycle from 1hr to 30mins. I thought this might have been the cause so we changed the OC back to one hour in length and contacted all their customers to collect the missing payments.

The week we see the same behaviour. No payments have been taken for their subscriptions.

Payment method is Stripe Connect. However this user might have been accidentally moved to Stripe SCA and then moved back. No idea if this is relevant.

Today I reopened the OC to try and force payments when it closed. No luck.

I would like to get to the bottom of why this is happening. I would like to:

• Force this weeks payments
• Understand why this is happening
• Any hacks to force subs payments to be taken are welcome, even if we have to do them each week while v3 is rolled out.

I am happy for any manual hacks to work around for this enterprise. Since we have already contacted all of the customers once I would like to avoid doing this again.

Enterprise: Farnham Community Farm ID: 200935 This impacts all of their subscriptions.

Expected Behavior

On closing of OC subscription payments are taken.

Actual Behaviour

No payments have been taken for these subscriptions since April 28th.

Steps to Reproduce

You can see the orders with outstanding balance for this enterprise. Shoppers have made a back transfer for payments missed between May 5th and June 16th.

I have not tried creating all the subscriptions. I am happy to do this, however, if we can force this week's payments to be taken first I would be very happy!

Animated Gif/Screenshot

Workaround

Severity

bug-s2: a non-critical feature is broken, no workaround

If we can resolve this user's issue manually or find any workaround I will happily downgrade this issue.

Your Environment

• Version used: 2.10.1
• Browser name and version:
• Operating System and version (desktop or mobile):

Possible Fix

[sauloperez]

I think this issue demands the same solution we're applying for https://github.com/openfoodfoundation/openfoodnetwork/issues/5449. We need to see why those payments fail.

In the meantime, we need to find a way to force these payments from the console. This will surely show us what's the underlying issue.

[lin-d-hop]

Payments failed for Farnham COmmunity Farm

[lin-d-hop]

Payments failed for Farnham COmmunity Farm

[lin-d-hop]

It is possible we moved to Stripe SCA and then back by mistake for this user. This would have broken the saved cards.

Damn!

[luisramos0]

I see all payments are there but have no cards connected. select p.* from subscriptions s, proxy_orders po, spree_orders o, spree_payments p where s.shop_id = 200935 and s.canceled_at is null and s.paused_at is null and po.subscription_id = s.id and po.order_id = o.id and o.id = p.order_id order by p.updated_at desc;

I need to see why the process is not picking up the credit cards in the system for the payments. This part of the code was heavily refactored during the stripeSCA work. I am tending more to a bug in the code than a problem with moving between stripesca and stripeconnect, we need to investigate that. I have 2 v3 S1s to look at tomorrow. Maybe I will only get to this one on Monday.

[lin-d-hop]

Hi @luisramos0 Just wanted to check you'll get to this today. The next subscriptions are meant to go through tomorrow and I need to let the user know what's going on.

[luisramos0]

I am now pretty sure there's a little bug somewhere when fetching the user saved card. But I have not managed to nail it yet... Do you have the confirmation email sent to the hub manager? Does it contain "There are no authorised credit cards available to charge"?

[lin-d-hop]

Ping @luisramos0

[luisramos0]

really? :-O I dont understand, tomorrow I will get the uk live DB to my computer and debug the process locally.

[luisramos0]

Summary: I can replicate this, I understand the cause and I think the improvement issues already on dev ready are exactly what we need to avoid this problem again.

Details: one of the 10 users (I'll DM the user name @lin-d-hop ) only has an expired credit card (2020/04) and that makes the confirmation process fail for all subscriptions. Pausing that user's subscription or adding a valid credit card will fix the process. That will be the quick fix for today @lin-d-hop

In terms of actions: We need to extend #4983 to the confirmation job as well. So that when one of the confirmations fails the rest can still get through. This total fail of the 10 failed subs will not happen again after #4983. Only one sub will fail.

Actually this error has a bugsnag alert but we missed it!

It also appeared on slack, only once, on May 5th:

I do read all these alerts but I must have missed because "Card expired" is a common error on checkout and can be ignored. I must have failed to see that this particular one was in the subs job... so, we need to extend https://github.com/openfoodfoundation/openfoodnetwork/issues/4981 to the confirmation job as well so that we get a specific bugsnag message with appropriate details.

So, I think today we can probably fix the card or pause the subscription and confirm the rest of the process goes well when OC closes. If that is the case, I think we can close this issue and keep the plan to get #4983 and #4981 done.

[sauloperez]

Sounds good. I ran across exactly that error last week and we briefly talked about it. I really want to get to #4983 and #4981 as soon as I can.

[luisramos0]

ok, the problematic subscription must have been removed, I see 9 processsed orders yesterday, 8 succeeded payments and one failed payment. Some problem with the stored credit card.

For this one I see the error: "You cannot use a Stripe token more than once: tok" This tok is usually stored for credit cards used only once at checkout (stored cards will have code card_). But for some reason it got tagged as the default card of this user... This is 100% StripeConnect so maybe we can ignore OR we can open a new issue it.

[lin-d-hop]

The failed card is a known issue. Thanks for this. We've not mostly sorted the admin faff around this issue. Closing.

[lbwright22]

Two further subscription payment failures this week (7th July) for Farnham:

R104311767 got sent an email to say Stripe token can not be used more than once- this is a card issue isn't it? Does the user need to remove their currrent card details and reenter (selecting the new card as default with permission for charges from Farnham) for it to work?

R278057011 went through fine when OC opened but payment wasn't taken when OC closes, or at least the order is showing as 'blanace due' and 'checkout'. No emails to say anything about the error though.

[lin-d-hop]

Hi all, I'm reopening this issue because it has happened again. Same enterprise. Two successful orders, which payments have succeeded in Stripe. The rest have failed.

Not a happy user :-(

[luisramos0]

The subs were correctly placed and confirmed, all 11 orders completed. 2 payments were processed and then one payment failed and the process stopped there.

From the 11 subscriptions, 2 users have expired credit cards saved as their default credit cards. Users Alis... and Astr...

With #4983 (being tested now) 9 payments would work and 2 would fail :ok_hand: Did the manager get the summary email? After #4983, the manager will get the summary email for sure.

With #4981 (also being tested now) we will have a slightly better bugsnag alert. I am not sure we would notice it with so many things happening at the same time but I think it will be better than this (we got this yesterday on slack):

Shall we close this (or mark prod-test) and re-check this after the fixes above are live? We can also create an extra improvement here about alerting hub managers of users credit cards expiring soon.

[lin-d-hop]

Right now my only priority is taking money from shoppers. Is that impossible?

[lin-d-hop]

Ok, given that actually collecting money from shoppers is impossible let's just do what Luis says.

[kirstenalarsen]

hey @lin-d-hop you probably don't want to know this now if you are on leave - but I rediscovered how to do that from stripe the other day - as in take the money from the shopper ourselves . .

[sauloperez]

We just merged https://github.com/openfoodfoundation/openfoodnetwork/pull/5751 which should considerably improve this situation.

[lbwright22]

@sauloperez @luisramos0 this week subscription orders have gone through again without payments being taken for a number of customers. Enterprise is Farnham Community Farm again. Order confirmation email sent to Farnham says that 14 subs have gone through correctly but payments are outstanding on:

R738430703

R276430124

R364313722

R260411435

R476361783

R724580104

R627772153

R527507128

R778527617

R386226402

R386226402

ie 11 out of the 14

[luisramos0]

hello, it will be the same problem right? one of the payments failed and the process stopped.

On Thursday, 13 August 2020, lbwright22 notifications@github.com wrote:

@sauloperez https://github.com/sauloperez @luisramos0 https://github.com/luisramos0 this week subscription orders have gone through again without payments being taken for a number of customers. Enterprise is Farnham Community Farm again. Order confirmation email sent to Farnham says that 14 subs have gone through correctly but payments are outstanding on:

R738430703

R276430124

R364313722

R260411435

R476361783

R724580104

R627772153

R527507128

R778527617

R386226402

R386226402

ie 11 out of the 14

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/openfoodfoundation/openfoodnetwork/issues/5670#issuecomment-673341430, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAMQPOUESSZWWYFUA4OECBDSAOQGJANCNFSM4OIGYFDQ .

[Matt-Yorkley]

This should be fixed by https://github.com/openfoodfoundation/openfoodnetwork/pull/5751

[luisramos0]

5751 is merged so I am closing this issue as closed by #5751

We can reopen if we find out #5751 did not fix it.