Payment details not updated between failed attempts

[alexflorisca]

Describe the bug

If we get a certain type of payment error on checkout, the stripe payment data (including the stripe key) does not get refreshed on subsequent attempts, and stripe fails with a generic error.

For each checkout store API call, we send a payload with a payment_data field. This has the details of the stripe payment made (assuming stripe). This payment_data comes from a callback/observer that stripe registers, which executes on the PAYMENT_PROCESSING event. One of the props of this payment_data object is a stripe_key which should be different for each payment attempt. As the payment_data is not being refreshed between payment attempts, stripe will error as we are trying to essentially create a payment that already exists.

To reproduce

This can be seen by:

1. Checkout with stripe with the card: 4000 0000 0000 9979 (this is a stripe test card that should return a Card has been declined message).
2. You should see the Card has been declined message in the payment options area. This is expected. You will also see a generic error at the top of the page, ignore this.
3. Click on "Place Order" again
4. You will see a different error message within the payment area "Sorry, we are unable to process your payment at this time. Please retry later." Instead, this should be the same "Card has been declined" error
5. You can optionally inspect the network requests made to the store API /checkout endpoint and notice that the payload fields of payment_data[].stripe_source is the same on both requests.

Expected behavior

I would expect the stripe payment data to have refreshed before sending it as the payload to the Store API /checkout endpoint, and to see the same "Card has been declined" error message each time.

To Fix

Note this is only visible after we merge the data store branch, as there is an error on trunk that prevents payment notices from showing.

The solution is to make sure the PAYMENT_PROCESSING event is emitted every time we click the place order button, before the call to the store api. We also want to make sure the paymentData is updated in the payments store.

[github-actions]

This issue has been marked as stale because it has not seen any activity within the past 60 days. Our team uses this tool to help surface issues for review. If you are the author of the issue there's no need to comment as it will be looked at.

[alexflorisca]

After investigating this further, this isn't a problem with the Checkout Block, but there may be an issue with the Stripe backend processing.

The PAYMENT_PROCESSING event gets emitted before every fetch to the StoreApi /checkout endpoint on clicking "Place Order", so that's all good. What happens the first time, is the stripe plugin creates a source based on the payment and customer information and returns a bunch of payment data, including a stripe_source key. All groovy. On the second payment attempt, when all the customer and payment information is exactly the same, it doesn't create a new source, it uses the previous sourceId for the stripe_source key. This makes sense, why create a new payment source when nothing has changed?

This payment data object (with the same stripe_source key as before), is then passed to the fetch to StoreApi /checkout endpoint. This take a while to return, and the $payment_result here includes a different error message.

So this is how stripe behaves, it's nothing to do with the Checkout Block. It would be nice to return a consistent error message though, so the next step would be to look at the stripe plugin and it's APIs and maybe fix it there. I will try to move this issue there, and if not possible, open a new one

[github-actions]

Hi,
This issue has gone 150 days (5 months) without any activity. This means it is time for a check-in to make sure it is still relevant. If you are still experiencing this issue with the latest version, you can help the project by responding to confirm the problem and by providing any updated reproduction steps.
Thanks for helping out.

[github-actions]

This issue has gone 180 days (6 months) without any activity.