Openfoodnetwork: Failed Orders / Payments for Prom Coast Food Collective

[emilyjeanrogers]

Description

Customers of Prom Coast Food Collective in Aus have reported being unable to place orders. Possibly some / all are seeing an error "Check Payment Pathway".

Investigation of Orders for this food hub shows approx 50 successful (completed / paid) orders and approx 180 unsuccessful or incomplete (cart / balance due) orders. Most of the incomplete orders are empty carts with $0 owing.

Expected Behaviour

Payment Successful for all orders

Actual Behaviour

What we know so far is that some customers are unable to check out and are getting an error message that says 'check payment pathway'. They are using Stripe as the only available payment method. They have used Stripe consistently for ages. The Order Cycle opened today (17th March 2020) and as at 2.45pm there have been 60 successful Stripe transactions.

Waiting for more information from customer about the unsuccessful transactions.

Steps to Reproduce

For some customers, they are trying to check out and getting this error. Not all customers. We don't know why yet

Could it be new Stripe-SCA? We have not yet switched them, should we try doing it?

Animated Gif/Screenshot

Workaround

Severity

bug-s1: a critical feature is broken: checkout, payments, signup, login

[mkllnk]

I can't find anything related in Bugsnag and I can't find that error message anywhere. Maybe it's something we should ask Stripe about. It's just difficult to replicate because people won't give us their credit card details for testing. :trollface:

[kirstenalarsen]

[kirstenalarsen]

[luisramos0]

A failed payment will not empty the cart.
If a user loads the shop page, an empty cart will be created.
Also, immediately after checkout, a new empty cart will be created for the user. So, those 180 empty carts are not relevant for the analysis.

They have monthly OCs and are now running an exception second OC in March, these are the number of orders for each OC:
JANUARY OC:
state | count
----------+-------
canceled | 1
cart | 1194 - of which 111 are not empty (~9.3%)
complete | 105

FEBRUARY OC:
state | count
----------+-------
cart | 1084 - of which 99 are not empty (~9.1%)
complete | 147

MARCH OC:
state | count
----------+-------
canceled | 1
cart | 1057 - of which 79 are not empty (~7.4%)
complete | 159

EXCEPTIONAL MARCH OC opened 17th March:
state | count
----------+-------
canceled | 1
cart | 693 - of which 96 are not empty (~13.8%)
complete | 95

Overall the numbers look good, this is an exceptional cycle and it was the first day and we already have almost as many completed orders as in JANUARY.

There's a slightly higher rate of non-empty carts in this last OC...

I need to continue the investigation but I wonder, did we ask the manager what users experienced errors? That would be very useful information.

[luisramos0]

Currently we dont have any way to track these cases, the connection to stripe is done on the browser and we dont have any logging in place after the connection to stripe is done and fails.
It's a massive logging hole, if adding a card to stripe fails for the user we need a message to be sent to our server saying what user tried it and some error message details.
I believe we can do this because the error message will not contain the card details.
If you agree I can create an issue to get this done so next time we are better prepared.

Tech details

Here's where we simply show the user the error message and stay on the checkout page:
https://github.com/openfoodfoundation/openfoodnetwork/blob/0f2e23d22574bdeba6ec6c6cac80bc62489555f6/app/assets/javascripts/darkswarm/services/stripe_elements.js.coffee#L17

[luisramos0]

The only other thing I see we can do here is to find out what users failed to checkout and ask stripe if they can provide more details about the error.

[kirstenalarsen]

OK I'll try and get more info about which users it was. I think it would be great to progress an issue on logging from Stripe - we're investing so much in Stripe as main payment gateway, it would be really good to know if, when and for who it fails!! I would support doing this asap, because i think it will be really calming and useful as we roll out stripe sca. What do you think @lin-d-hop ?

[Matt-Yorkley]

We can't write log entries directly from within that Angular service... so maybe could pass the error to an endpoint that then writes it to the log, but that would mean anyone could spam that endpoint and write things to disk on the server, which is not nice... so maybe we can just send it straight to Bugsnag... but if we made it available in our javascipt, then our Bugsnag key would be visible, which isn't nice either...

This is a fun problem.

Maybe a logging endpoint, but drop all requests that aren't from the same domain as the server itself? I think we have big logging holes in our javascript in general, so it could be broadly useful elsewhere as well?

[mkllnk]

Bugsnag has a Javascript integration. We are using that at Ceres Fair Food. I think it's simply including a script and it will report any errors in JS. I haven't used it to report other issues though. I'm not sure how easy it would be to hook into the Stripe code to report these errors because they are not seen as error. They are just feedback to the user why the payment failed.

[luisramos0]

As far as I can see in the our code, these errors are reported as errors by the stripe api and we are showing them on the error bar to the user. So we have access to the error.

I think we should build a simple JS logging service that sends logs to an endpoint in our server. The endpoint can be protected by authentication. I think there will be too many errors to use bugsnag in this case. Many of these errors will just be user errors, invalid cards details, etc.

[Matt-Yorkley]

I think we should build a simple JS logging service that sends logs to an endpoint

Sounds good :+1:

The endpoint can be protected by authentication.

Anyone can log in though, and then the endpoint would be easily accessible, right? And what about guest checkout...?

I think creating an endpoint that takes user input and writes it directly to disk is something we should approach with _extreme_ caution...

[daniellemoorhead]

Closing this as we haven't it reoccur since reporting.

[luisramos0]

@daniellemoorhead I think we usually close issues when actions are decided.

We may skip contacting stripe with user ids to get more details but I'd implement the logging.

[daniellemoorhead]

No worries @luisramos0 I was working off what @kirstenalarsen and @mkllnk said was ok to do. If a logging card needs to be created then did you want to do that?

[luisramos0]

I think it's a product decision to do it or not.
I agree with @kirstenalarsen, I'd say this is up to @lin-d-hop to agree we should invest some money in improving the logging for failed stripe payment attempts. It's not an XS story, maybe S or M.

[kirstenalarsen]

I think we are now investing in logging for failed stripe attempts?!

[luisramos0]

yeah.
I am not 100% sure about this but here it goes: Kirsten that very first bugsnag alert we saw today about a failed payment looks like a payment that triggered a rejected card by stripe and is currently a silent checkout for the user.