Openfoodnetwork: Subscription Payments Failed for Enterprise
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
lin-d-hop
All 24 comments
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.
sauloperez
on 25 Jun 2020
lin-d-hop
on 25 Jun 2020
lin-d-hop
on 25 Jun 2020
It is possible we moved to Stripe SCA and then back by mistake for this user. This would have broken the saved cards.
Damn!
lin-d-hop
on 25 Jun 2020
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.
luisramos0
on 25 Jun 2020
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.
lin-d-hop
on 29 Jun 2020
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"?
luisramos0
on 29 Jun 2020
Ping @luisramos0
lin-d-hop
on 29 Jun 2020
really? :-O I dont understand, tomorrow I will get the uk live DB to my computer and debug the process locally.
luisramos0
on 30 Jun 2020
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.
luisramos0
on 30 Jun 2020
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.
sauloperez
on 30 Jun 2020
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.
luisramos0
on 1 Jul 2020
The failed card is a known issue.
Thanks for this. We've not mostly sorted the admin faff around this issue.
Closing.
lin-d-hop
on 3 Jul 2020
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.
lbwright22
on 8 Jul 2020
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 :-(
lin-d-hop
on 4 Aug 2020
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.
luisramos0
on 5 Aug 2020
Right now my only priority is taking money from shoppers.
Is that impossible?
lin-d-hop
on 6 Aug 2020
Ok, given that actually collecting money from shoppers is impossible let's just do what Luis says.
lin-d-hop
on 6 Aug 2020
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 . .
kirstenalarsen
on 7 Aug 2020
We just merged https://github.com/openfoodfoundation/openfoodnetwork/pull/5751 which should considerably improve this situation.
sauloperez
on 10 Aug 2020
@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
lbwright22
on 13 Aug 2020
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
.
luisramos0
on 13 Aug 2020
This should be fixed by https://github.com/openfoodfoundation/openfoodnetwork/pull/5751
Matt-Yorkley
on 15 Aug 2020
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.
luisramos0
on 16 Aug 2020
Related issues
kirstenalarsen
·
3Comments
Matt-Yorkley
·
3Comments
sauloperez
·
3Comments
filipefurtad0
·
3Comments
filipefurtad0
·
3Comments