JSON error after authorization attempt for a failed Stripe payment

[filipefurtad0]

Description

Authorizing a previously a failed Stripe payment leads displays the error:
"The source_redirect_slug parameter is invalid"

Please note that it is the Payment Status which is Failed; not to be confused with Payment State 👀

Expected Behavior

Snail should be displayed?

Actual Behaviour

The user sees a backoffice error message: "The source_redirect_slug parameter is invalid"

Steps to Reproduce

As admin:

1. Add a Stripe SCA payment to a BO order
2. Make that payment fail -> how to achieve this?? Currently BO payment status is not updated, when the payment fails... Needs investigation, and possibly another issue.

As the customer:
3. Visit /account#/transactions
4. Click Authorize, for that payment
5. See the error.

Animated Gif/Screenshot

Workaround

?

Severity

Maybe not an S2, but worth investigating?

Your Environment

• Version used: v.3.7.2 - Unsureif it was introduced here...
• Browser name and version: Firefox 88
• Operating System and version (desktop or mobile): Desktop Ubuntu 20.04

Possible Fix

[Matt-Yorkley]

That string source_redirect_slug doesn't appear anywhere in our codebase, and it also doesn't appear in the source code of current versions of either the ActiveMerchant or Stripe gems... 🤔

[Matt-Yorkley]

But it's clearly in the URL there...

[Matt-Yorkley]

I notice from the GIF that payment you were trying to process was at least a month old. Could that be a factor? Maybe we changed something in staging during that time? Maybe it's considered too stale to be processed?

[Matt-Yorkley]

Ah, the order had two different Stripe payments... maybe related to #7278 ?

[filipefurtad0]

There is something very broken about that order and payments... I have no idea how to reproduce that scenario:

• a failed Stripe payment - in which the payment status is failed - I think this might have been working at some point, but right now, if a backoffice Stripe payment fails then the payment status remains pending -> it does not change to failed (I'll try to reproduce this through the shopfront and/or subs, maybe it works in those cases)
• a Stripe payment, with the "Capture" button - as far as I know, the button to manually capture payments only is displayed for manual payments (ex. cash).

I think this is unrelated to #7278, which relates more to incorrect UI behavior.

I'd think this issue relates #7601 - if an authentication was attempted (and succeeded or failed), then the "Authorize" button should not be accessible to the customer.

I'm thinking, maybe we can find other Stripe SCA payments with payment status in the DB and try to authorize them through the UI? I wonder if we can find these in production or staging...

[Matt-Yorkley]

Is the authorization working on other orders then, and it's just this one order that's broken?

[filipefurtad0]

Payment authorizations work as before 👍 I don't think the payments are breaking. This is perhaps a just an unwanted side effect of having the piling up of authorize buttons under /account/transactions... And even perhaps per-existant to this release.

[filipefurtad0]

I'm not sure this is the best way but I ran this query in staging-UK:

SELECT * FROM spree_payments WHERE state = 'failed' AND response_code != '';

Which returns some payments with a similar cvv_response_message :

   id   | amount | order_id |         created_at         |         updated_at         | source_id |    source_type    | payment_method_id | state  |        response_code        | avs_response | identifier | cvv_response_code |                                                                                                                cvv_response_message                                                                                                                 
-------+--------+----------+----------------------------+----------------------------+-----------+-------------------+-------------------+--------+-----------------------------+--------------+------------+-------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
 33652 |  10.00 |   445576 | 2021-04-30 14:52:00.675695 | 2021-04-30 14:52:30.384289 |      4042 | Spree::CreditCard |               751 | failed | pi_1IlxhGKuuB1fWySnSCdYXcim |              | U2Q2YZDC   |                   | 
 33615 |  28.00 |   445475 | 2021-04-27 17:33:03.231485 | 2021-04-27 17:33:16.402967 |      4024 | Spree::CreditCard |               751 | failed | pi_1IkumTINgqg5gQHbdf7G9g9K |              | 2KC5VD43   |                   | https://hooks.stripe.com/redirect/authenticate/src_1IkumTINgqg5gQHbTRSraVvy?client_secret=src_client_secret_lDTHLkieIucctQ8iaOtA97Fu&source_redirect_slug=test_YWNjdF8xSWtWWlFJTmdxZzVnUUhiLF9KTmc4TDhkMGZyMUVLa1pRcHRWNmxhVVJHaVlmWldM0100InEGJ7MZ
 33660 |  12.00 |   445152 | 2021-05-03 09:36:44.703826 | 2021-05-03 09:36:56.330485 |      4045 | Spree::CreditCard |               751 | failed | pi_1ImyCoKuuB1fWySnPIfHutLj |              | S5SCXL4C   |                   | https://hooks.stripe.com/redirect/authenticate/src_1ImyCpKuuB1fWySntfb2SCVd?client_secret=src_client_secret_OuruyomWzawh85CpNZQL5iFt&source_redirect_slug=test_YWNjdF8xRmlxRXNLdXVCMWZXeVNuLF9KUG5vaU1VR1F2SGFpY1RDVU1qUDNUR083ejhXbHQw01000hatxdbv
 33655 |   6.00 |   445578 | 2021-04-30 15:06:27.136648 | 2021-04-30 15:06:37.177335 |      4017 | Spree::CreditCard |               744 | failed | pi_1IlxvEKByMaXUno0Y5riKxo3 |              | PNGP3HMZ   |                   | https://hooks.stripe.com/redirect/authenticate/src_1IlxvEKByMaXUno0NepTefwV?client_secret=src_client_secret_hhmVYevEIUFGzQhdu1KoARx2&source_redirect_slug=test_YWNjdF8xSWdwVk1LQnlNYVhVbm8wLF9KT2xTQ3BLRXQ0dkZ5YVpJZGtrSWxFeGIyS1lUN1FY0100pmvGt2UR
 33650 |  10.00 |   445576 | 2021-04-30 14:44:46.85896  | 2021-04-30 14:45:20.247597 |      4040 | Spree::CreditCard |               751 | failed | pi_1IlxaGKuuB1fWySnzNpcPhH6 |              | 84M4B69R   |                   | 
 33735 |   1.00 |   446214 | 2021-05-25 10:16:10.817439 | 2021-05-25 10:17:52.985642 |      4068 | Spree::CreditCard |               756 | failed | pi_1IuxJ2LP6x4awOu5rfwzeVcb |              | RGCL2ZQS   |                   | https://hooks.stripe.com/redirect/authenticate/src_1IuxJ2LP6x4awOu5iQsGYfK0?client_secret=src_client_secret_9RGUggOsxDAwPAfETW1YmVjd&source_redirect_slug=test_YWNjdF8xSXV4OFdMUDZ4NGF3T3U1LF9KWTNQVU5xc3FDeHRldzRiVlhHdE92QzhGcndrVndl0100cpr2sT0H
(6 rows)

I'm guessing clicking on any of these will display the same message...

[filipefurtad0]

Ok this is found payment on staging-katuma (the latest release was not staged on this server):

 id  | amount | order_id |         created_at         |         updated_at         | source_id |    source_type    | payment_method_id | state  |        response_code        | avs_response | identifier | cvv_response_code |                                                                                                                cvv_response_message                                                                                                                 
-----+--------+----------+----------------------------+----------------------------+-----------+-------------------+-------------------+--------+-----------------------------+--------------+------------+-------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
 204 | 111.20 |     1228 | 2021-04-21 14:56:17.921119 | 2021-04-21 14:58:40.232063 |        32 | Spree::CreditCard |                 9 | failed | pi_1IihTVC5Cj6Ku9eAPksZCiYb |              | BHYWMBSC   |                   | https://hooks.stripe.com/redirect/authenticate/src_1IihTVC5Cj6Ku9eAjiJt0HWk?client_secret=src_client_secret_nrmp7oCbXhXnMalCeXxwzpJ7&source_redirect_slug=test_YWNjdF8xSWR3a25DNUNqNkt1OWVBLF9KTE9HVmdqN3hqTDl1T2o2U3JXM1JpRVpIWVB0Uk9G0100BLvCnDF8

Following the link on the cvv_response_message will display the error message as well - so this confirms it is not introduced by this release 👍

I'm wondering if this silent error is occurring in production as well - I can't seem to access spree_payments from UK-prod through Metabase...

[andrewpbrett]

The source_redirect_slug param is present in the authorization URL, so it's Stripe that's complaining about it not being valid. I don't see it anywhere in their docs, but it seems pretty likely that the issue is that we're trying to authorize a payment that's already failed authorization or that that URL is no longer valid in some way.

The root cause is really that if the payment is in state failed:

1. cvv_response_message should be nil
2. The payment shouldn't show up on the list of payments that require action

#7708 should take care of the second part, at least in the future, as that list of payments will be limited to payments that are in the requires_authorization state. And I just added a commit ab55186 that clears the cvv_response_message when we move the payment to the failed state, just for good measure. So I'd say that if we get #7708 merged, we can close this.

Maybe we could run that same query on production servers and clear the cvv_response_message on any existing payments that are in the failed state in the meantime?

[filipefurtad0]

So, for the record, in production UK we have:

openfoodnetwork=> SELECT COUNT(*) FROM spree_payments WHERE state = 'failed' AND response_code != '';
 count 
-------
    12
(1 row)

But no results for slug-like cvv response messages, which is good:

openfoodnetwork=> SELECT COUNT(*) FROM spree_payments WHERE cvv_response_message LIKE '%slug%';

-------
    0
(1 row)