Attention: Aleksandar Vuković

This is a follow-up to the previous tickets:

 https://tmsplugins.ticksy.com/ticket/3673518 

 https://tmsplugins.ticksy.com/ticket/3481698/

Subject: Critical issue: duplicate bookings in classes + proposed native solution

Hi Amelia team,

I’ve been using Amelia Elite for quite some time now to manage class bookings for my clients — specifically Pilates Reformer studios that run multiple class schedules throughout the day.

About a 10 months ago, I reported a critical issue that unfortunately still hasn't been resolved (Please see tickets: https://tmsplugins.ticksy.com/ticket/3673518 and https://tmsplugins.ticksy.com/ticket/3481698/ ) , and I’d like to explain it again as clearly as possible and propose a practical, native solution that would address it definitively. The issue is now occurring more frequently as we’re currently managing 6 websites with a growing number of active clients. My client is becoming increasingly frustrated and is urgently asking for a resolution. We’d sincerely appreciate your prompt attention and support in resolving this issue.

The problem: duplicate bookings occur when availability is limited

When two customers attempt to book the same class at the same time, it’s currently possible for both of them to successfully complete the booking — even if only one space was available.

This issue doesn’t only happen with the last available slot, but it becomes much easier to reproduce in that scenario, since there’s only one space left and both users race to claim it simultaneously.

To demonstrate the problem, I’ve recorded a video using a desktop and a mobile device, simulating two users booking the same class. I’m doing this test on a staging site, where I’ve prepared the scenario by intentionally leaving just one space available for the selected time slot. In this link you can find a video for your review: https://share.icloud.com/photos/0b3Kz9wyLWpObaVFxwcgBx-XQ

I will give you credentials to this stage site in private ticket and the scenario is ready again with only one space available, employee / Reformer NG03 Pilates, for  may 2th de 2025 at 7:00 am for in the case that you want to try.

Real-world example: how airlines handle this issue

Booking systems in industries with high-stakes availability — such as airlines — avoid this issue using a mechanism called a "soft hold." When a customer begins the checkout process, the system temporarily locks the selected seat or spot, making it unavailable to others while the user completes payment.

If payment is not completed within a predefined time (e.g., 5 minutes), the hold is released, and the spot becomes available again.

This is a standard expectation in any modern booking system — whether for flights, concerts, or classes.

My proposal: a native solution in Amelia

I’d love for Amelia to implement a similar "soft hold" system, especially when used in combination with WooCommerce. Here's how it could work:

1. When a customer proceeds to checkout for a class, Amelia should temporarily hold the spot for a limited time window.
(Option in settings to define the desired temporary hold duration in minutes)
2. During that window, the spot would be unavailable to others.
3. If the payment is successful, the booking is confirmed.
4. If the payment fails or isn’t completed in time, the spot is automatically released.
5. As an optional feature, if the time is about to expire and payment has not been completed, a popup window could appear notifying the user and asking if they need more time.

This logic would solve the root issue of duplicate bookings and help maintain inventory integrity in high-demand classes.

Why I prefer to continue using WooCommerce for payments

I prefer using WooCommerce for payments because it gives me full control over the purchase flow and integrates well with the broader WordPress ecosystem. It also gives me access to native hooks like `payment_complete` and `payment_failed`, which are useful for handling logic around bookings and payment statuses.

I previously tried using the hidden "book before payment" option (which was suggested via support), but that solution introduced an even more serious issue: when a payment was declined, the booking was still registered — and several customers quickly discovered and took advantage of this loophole.

In summary

This issue directly affects the reliability of the system and has been known for quite some time without a complete fix.

I kindly urge you to consider implementing a native "soft hold" mechanism during the checkout process when using Amelia with WooCommerce, in order to prevent simultaneous bookings of the same class spot.

I’m happy to help with testing or feedback if needed.

Thank you for your time and for the work you do,  

Carlos Atristain

Hi Uros,

Thank you for your prompt and considerate reply.

Yes, I would very much like you to proceed with the solution you described — ensuring that bookings are only confirmed once payment is successfully completed. That approach would resolve the core issue and help prevent duplicate bookings, which is especially important for our high-demand classes where space is limited.

I’m glad to hear your team recognizes the importance of this functionality, and I really appreciate your willingness to consider improvements on this front. Please do keep me informed of any progress, timelines, or updates, as we would be happy to assist with testing or feedback if needed.

Thank you again for your attention and support.

Best regards,
Carlos

Dear Uros,

Thank you again for your continued support and for setting up the logic to ensure bookings are confirmed only after successful payment.

I’ve run several tests on my end, and I believe your solution is quite close — it may just need a bit more refinement to fully resolve the issue.

✅ TEST 1: PREVENTING DUPLICATE BOOKINGS
On May 30th at 7:00 AM, I set up a class with only one available spot. I then attempted to simulate two users booking at the same time — one from my laptop and another from my phone — both reaching the checkout simultaneously using different customer accounts.

>>> Ideally, if one user is already at the checkout, the class slot should no longer appear available to other users for a limited time (e.g., while the first user completes payment or until a timeout is reached). However, we can leave that aspect for a later refinement in order to offer a smoother user experience — where the second customer doesn’t have to go through the entire booking and payment process only to be notified at the end that the slot is no longer available, and then has to start over (especially when they are scheduling up to 20 classes as part of a package).

Both users entered valid credit card details (Stripe test cards like 4242 4242 4242 4242) and clicked "Place Order" at the same time. This previously led to duplicate bookings, but in this test, I’m pleased to report that only one reservation was made, which is a great improvement.

⚠️ TEST 2: BOOKING WITH FAILED PAYMENT

I then tested a more straightforward case:
Again, the class on May 30th at 7:00 AM had only one available spot. I went to checkout and purposely used Stripe test cards that simulate declined transactions, such as:

• 4000 0000 0000 0002 – Generic decline

• 4000 0000 0000 9995 – Insufficient funds

• 4000 0000 0000 9987 – Lost card

• 4000 0000 0000 9979 – Stolen card

WooCommerce correctly displayed the appropriate error message about the payment being declined. However, the booking was still registered in Amelia — even though the payment failed.

You can view the video here:
🔗 https://www.icloud.com/iclouddrive/033OapPyx07KnABpY1J4sX6pw#20250506_013433

Two issues arise in this scenario:

1. If the customer tries to enter a new, valid card after the failed attempt, WooCommerce blocks the process with the message:
   “You have already booked this appointment.”
   — preventing the transaction from being completed.

2. If the customer gives up and simply closes the page, the booking still remains in Amelia, despite no successful payment ever occurring.

🤔 QUESTION ABOUT BOOKING METADATA
While analyzing this, I noticed that Amelia doesn’t generate the appointmentId during checkout — it only becomes available after payment is successful. That means WooCommerce orders don't receive the actual booking ID as part of the metadata.

Is this behavior expected, or is it a limitation?
If the appointmentId were available earlier, it could be extremely useful — for example, to detect and automatically remove reservations if a payment ultimately fails or is abandoned.

📝 SUMMARY

Your recent changes are certainly helping, and I appreciate the progress. That said, to fully resolve the issue, I believe the following two improvements are still needed:

• Ensure that failed or abandoned payments do not leave orphaned bookings.

• Prevent customers from being blocked from retrying payment when the first attempt fails. (Or alternatively, offer a mechanism to clear/retry gracefully.)

Please let me know if any of these issues are currently being worked on, or if you’d like more information from my tests.

Thank you once again for your time and effort.

Best regards,
Carlos Atristain