Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Payment attempts on orders with stock restrictions appear as authorized and "uncaptured" on Stripe #7922

Closed
filipefurtad0 opened this issue Jul 13, 2021 · 2 comments · Fixed by #7990
Assignees
Labels
bug-s2 The bug is affecting any of the non-critical features described in S1 and there is no workaround.

Comments

@filipefurtad0
Copy link
Contributor

Description

Related to #7692.
Follow-up issue from #7779 - This PR introduces a warning to the user about an unsuccessful payment when stock is reduced, when the payment awaits for SCA authentication; it also removes doubling of transaction fees, on every payment attempt.

However, for that scenario, he payment still goes through as authorized and authenticated, appearing as "uncaptured" on Stripe.

Both payments appear on Stripe, (1) and (2):

  • The first payment attempt (1) above appears in Stripe as an authorized, but Uncaptured payment;
  • The second and successful payment attempt appears in Stripe as a Succeeded payment;

image

Expected Behavior

Payment attempts on orders with stock restrictions should be voided, when stock restrictions occur.

Actual Behaviour

Payment attempts on orders with stock restrictions appear as authorized and "uncaptured" on Stripe

Steps to Reproduce

As a customer:

  1. Add stock to cart
  2. Checkout with Stripe SCA
  3. Wait till the "Authorization screen" is displayed on the UI

As admin:
4. Set available stock to zero, for that item

As a customer
5. Click Complete Authentication (customer)
6. Check the Stripe Dashboard for that account - see the payment is appearing as uncaptured

Animated Gif/Screenshot

Steps to reproduce:
Peek 2021-07-13 12-52

Payment, on Stripe Dashboard:
image

Workaround

Cancelling the payment on Stripe:
image

Severity

bug-s3: a feature is broken but there is a workaround

Your Environment

  • Version used: v3.8.4
  • Browser name and version: Firefox 89
  • Operating System and version (desktop or mobile): Ubuntu 20.04

Possible Fix

@filipefurtad0 filipefurtad0 added the bug-s3 The bug is stopping a critical or non-critical feature but there is a usable workaround. label Jul 13, 2021
@RachL
Copy link
Contributor

RachL commented Jul 13, 2021

@filipefurtad0 when the payment in uncaptured on Stripe it has still left the shopper's bank account right? I'm wondering if this severity is not higher, but I'm highly confused by Stripe capture feature. I'm not sure what it is used for....

@filipefurtad0
Copy link
Contributor Author

Yeah, I'm wondering too...

An uncaptured payment still has not left the shoppers account, but the amount is reserved, and as such, not available to be used by the shopper for other purchases.

On https://stripe.com/docs/payments/capture-later:

Place a hold on a card to reserve funds now but only capture them after your business completes the service. For example, a hotel may authorize a payment in full prior to a guest’s arrival, then move the money when the guest checks out.

So... this means that in order to make the amount "useful" again on the customers account, the manager would have to manually void the payment. But this probably is not a useful workaround if we have several such payments...

Upgrading to S2, thanks for your feedback 👍

@filipefurtad0 filipefurtad0 added bug-s2 The bug is affecting any of the non-critical features described in S1 and there is no workaround. and removed bug-s3 The bug is stopping a critical or non-critical feature but there is a usable workaround. labels Jul 13, 2021
@Matt-Yorkley Matt-Yorkley self-assigned this Jul 27, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug-s2 The bug is affecting any of the non-critical features described in S1 and there is no workaround.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants