Stripe Plugin - Unhandled race condition during checkout when there is limited stock

[LeftoversTodayAppAdmin]

Describe the bug
Scenario:

• 2 customers, and only 1 item that they both have in their cart
• They start checking out at the same time
• I do a stock level check before creating the payment intent, it passes for both customers and I show the Stripe element
• Customer 1 is slower than Customer 2 at entering the credit card info and completing the payment
• Customer 2 finishes payment first, according to the code above the webhook is called with payment_intent.success and the item is allocated and is no longer available
• Customer 1 finishes the Stripe payment step after Customer 2, gets charged successfully, webhook is called with payment_intent.success but then item state change fails because the item stock is zero at this point

Outcome:

• The Stripe payment goes through and then moving the order to ArrangingPayment step fails because between the final stock level check on the payment page and completing the Stripe payment, the stock for one of the variants in the order went to zero.
• The order remains in an AddingItems state.
• The order also gets into an inconsistent state because the intent that was created for the order was already fulfilled so even if the out of stock items are removed from the order, Stripe will not process the order anymore or send a success message to the Webhook.
• The Stripe Plugin will not create a new intent for the same order code either
• The only way to get out of this state is to manually cancel the order and issue a refund on Stripe

To Reproduce
Steps to reproduce the behavior:

1. Create a product with a variant that only has 1 item in stock
2. Have 2 different customers put the same variant in their cart
3. Use Stripe to checkout
4. Get both customers to the checkout flow where they have to enter their credit card information
5. One customer finishes first, then the second customer will see that the payment will go through but the order will not move to Arranging Payment because the item is out of stock, order remains in adding items state.
6. Order is now stuck. Stripe Intent is already used and completed and cannot be reused, Stripe Plugin will not create a new intent for that same order code.
7. Customer is charged but the order cannot be fulfilled

Expected behavior
A clear and concise description of what you expected to happen.

• Ideally this is what I think would handle this race condition gracefully - Separate authorization and capture (https://docs.stripe.com/payments/accept-a-payment?platform=web&ui=stripe-hosted#auth-and-capture)
• Stock check before creating intent
• Create intent and show the Stripe element
• Only authorize, dont charge the customer and update the webhook to listen to the authorization event
• On authorize, attempt to change item to allocated, this will fail if another customer grabbed the item first, in that case cancel the authorization with a message, unsure how to propagate the error to the storefront
• If stock exists and allocation can be successfully updated, then call the Stripe API to capture the payment for the same intent, which should then redirect to the URL

Environment (please complete the following information):

• @vendure/core version: 3.0.2
• Nodejs version: 20
• Database (mysql/postgres etc): MariaDB

Additional context
Add any other context about the problem here.

[michaelbromley]

Thanks for the report.

This is quite a tricky problem and the best solutions is dependent on the particulars of the commerce use-case.

Possible solutions:

• Backorders. By using a negative outOfStockThreshold you can handle this issue by treating the second order as a back-order. This works well if you have a regular re-stocking of your inventory.
• Early allocation. You allocate the stock as soon as a customer adds it to an order. This will prevent the second customer from adding it to their order and thus circumvent the payment issue. In this solution you would need to subscribe to the OrderLineEvent and then manually call StockMovementService.createAllocationsForOrderLines() when a line is created and when quantity is increased, and StockMovementService.createAllocationsForOrderLines() when quantity is decreased or a line removed. You would also have to put in place a time-based mechanism to release allocations & remove order lines after some time limit. You should also consider a mechanism to limit the quantity that can be added to a single order to prevent abuse.

In your case, I believe the products are short-lived and not suitable for a backorder-based approach.

In any case, this plugin should more gracefully handle the situation described above. Would you be interested in working on implementing the suggested solution? If so, we can collaborate on a design that avoids breaking changes for existing users.

[LeftoversTodayAppAdmin]

Hey @michaelbromley
Thank you for taking the time to read through the ticket and getting back to me. I definitely would be interested in working on a solution after I get the MVP out the door and before a full launch as this issue would negatively impact my customers eventually.

• Youre right, backorders would not work in my case
• Early allocation is also tricky since there are limited items for donation each day and hiding the item because someone else has it in their cart who may or may not complete the purchase will also affect the experience. This also requires a time-based release job which I anticipate will come with its own complications in a multi-region multi-server environment.
• I would love to discuss the Stripe approach of pre authorize the card to ensure there are funds but dont actually capture the funds until the stock has been allocated. This will keep all of the current logic the same, and only breakup the monetary transaction into 2 parts and the plugin would need to listen to a different authorize event along with the existing events - https://docs.stripe.com/payments/accept-a-payment?platform=web&ui=stripe-hosted#auth-and-capture

How do you propose we collaborate? I am happy to get on a video call at a time thats convenient for us both given the time difference between PST and CEST.

[michaelbromley]

I propose we do it like this:

• you take a look at the current implementation and see if you can isolate the parts that would need to be changed. A bullet list of each part with a link to the link from the source file would be great.
• propose what changes would be needed (if you are not 100% sure then just pseudo-code is fine to convey they general idea)
• I will review and offer my comments and once we agree on the general plan, you can try to implement and I can review as you go.

How does that sound? If we reach an impasse with the async approach then a call could be arranged, which we could arrange via Discord.