staging-UK: payments with Stripe-SCA - page not found after authentication step

[filipefurtad0]

Description

Checking out using Stripe SCA leads to a "page not found", after the authentication step, on staging-UK.

This seems only related to staging-UK. After staging master - https://semaphoreci.com/openfoodfoundation/openfoodnetwork-2/branches/master/builds/2204 - in staging-AU, I could not reproduce the issue.

Broken link:

https://demo.openfoodnetwork.org/checkout?payment_intent=pi_1INb0GKuuB1fWySnlcjek3UU&payment_intent_client_secret=pi_1INb0GKuuB1fWySnlcjek3UU_secret_7r254T92ftvzB97Y5C0eeEbbp

Console:

Steps to reproduce

1. As a customer, visit a hub, which has stripe-SCA set up
2. Insert some items and proceed to check-out
3. Insert card 4000002760003184 or any card which requires authentication
4. Try to authenticate, and finish the purchase

[filipefurtad0]

This seems to be the case, with staging Katuma as well:

But working on staging-FR, and AU. I'm using the same Stripe account to connect to all staging servers.

[filipefurtad0]

Perhaps not a Sysadmin issue, maybe even expected behavior, it needs further investigation. I'm moving this to All the things for now. I haven't found this error on production, so -> S4.

On orders/servers/(situations?) in which for some reason are not going through with a 3D-auth. card., payments with non-3D-auth. card (like 424242...) card triggers this error:`

RuntimeError: You cannot capture a payment for an amount greater than it already has`

https://app.bugsnag.com/katuma/katuma/errors/602cbf57d9fdda00188e2bbe?event_id=6034bfbd006ca08d237b0000&i=sk&m=nw

Attempting once again, with the 424242... card then works, but we can see the several attempts on the transaction fee:

A tentative explanation here is that Stripe charges a fee for 3D-auth. transactions. This fee is expected on the subsequent payment (non-3D-auth) which triggers the error. This would explain everything, except:

• that the hubs transaction fees pile up on the shopfront as well - although this seems to happen only in this scenario (1) attempting payment with a 3D-auth card, and, after failing, pay the order with a non-3D-auth card.
• the fact that 3D payments are not going through in some cases (the title of this issue)

[Matt-Yorkley]

It looks like the Spree::Config['site_url'] value has been reset to the default somehow (demo.openfoodnetwork.org). That's what's breaking the redirects. I imagine if you click a link in an email (like reset password) it will also be broken...

[filipefurtad0]

Yes, I just confirmed that now (for password reset). Wondering how we lost that config... After a deployment? 🤔

[Matt-Yorkley]

I've just reset it via superadmin, we can keep an eye on it...

[filipefurtad0]

Ok, it's back now - after restarting unicorn, changes took effect 👍

[filipefurtad0]

I think the issue can be closed now, but I'm thinking if we could somehow automate post-deployment checks. In /spec/features/admin/configuration/general_settings_spec.rb we have this like:

expect(find("#site_url").value).to eq("demo.openfoodnetwork.org")

Which is of course not catching changes in this field after deployment, on other environments...

We also had this issue in the past #5932 (which probably can be closed as well).

This issue/comment also seems related:
#6529 (comment)

How could we improve automatic post-deployment checks? Opened #6968.