Orders With No Items

We are getting quite a few orders with people somehow submitting orders with no items. You can tell based on the price what they ordered and the custom order text entry fields are still there, but no cart items. I had one parent do this 11 times somehow. We've had about 30 orders like this now over about 2000 orders. 

We do have an SSL Cert installed. We have tried having multiple variations of our URL in there(following the directions of "Most likely leave this blank. If your SSL only works with or without the www. prefix, enter in your SSL link above. Example: https://www.mysite.com (do not use a trailing slash). But your security certificate probably works with and without the www. If you don't know, just leave this blank.") and also leaving it blank and it hasn't seemed to make a difference in this occurring. 

There are no errors in the log for when this happens. The stripe payment does go through some of the time when this happens. 

I will ask my developer to post any additional details if there is anything that I missed or said wrong. 

Hello, I did some digging into this and found 3 interesting things of note. First, is that all of these orders seem to be duplicates of similar orders placed on Feb 25th based off order extra fields, and price totals. Second, is that in the access logs there are no visits from the users' IP Address that supposedly ordered these items for at least a week (IP Logging wasn't working correctly for apache until about a week ago, so I don't know before that, but I'm assuming last user access was 2/25). Third, I found an active cart (checkout not completed) from one user IP that had items in it that totaled to the amount shown in the created (empty) order, so I wonder if it has something to do with sessions?
Also, all these users seem to have placed two orders on 2/25 (intentionally - different order extra fields), but with two different session ids in the order session field. I am unsure if multiple sessions has anything to do with it though.

As for SSL info, our domain will not work if you add a "www." in front of the domain. Simply a requirement due to how subdomains work on our site.

I figured it out. We have 2 Sytist instances running, both linked back to the same stripe account. Because of this we have two webhook locations registered in the Stripe panel. Stripe (understandably) does not distinguish which events to send to which webhook, and sends all events to all webhooks. Because of this when an order from one Sytist instance is completed, it sends that event to the second Sytist instance as well. If there happens to be a pending order on the second instance with the same id as the just completed order on the first instance, it will create that order on the second instance.

As for why the carts have no items, I am not entirely certain. I believe it is if the user goes from Sytist checkout to Stripe payment multiple times, it will reassign the cart to a new pending order, and the old pending order, when created, has no items. This also means there are likely some orders in our list that are "fake" but have actual items in their cart. This is something I will have to figure out how to distinguish on our end, I believe trying to find duplicate payment intent ids will be the best way to go. 


Solution for folks who may show up here later:

Ideally you simply shouldn't do multiple instances of Sytist on one Stripe account. Use multiple accounts, that is the recommended strategy from Stripe anyway for multiple business fronts. In our case though, that is not a viable solution anymore, so our idea is that since ms_pending_orders.order_id is a INT AUTO_INCREMENT we can simply offset the AUTO_INCREMENT on the second instance to a much higher number, say 1,000,000 using the query below. 
ALTER TABLE ms_pending_orders AUTO_INCREMENT = 1000000;
This will set the pending orders created on the second instance start at id 1000000. The downside of this method, is that you now have a 1000000 pending order window before this issue starts to happen again, since some pending orders are never removed from the table (due to incomplete checkout, or webhook misconfigurations). Eventually ids from the first instance will creep up to that id range and start to have duplicates with the second instance again, and more fake orders will come in. You also could occasionally clear the ms_pending_orders table of very old orders, although I would not recommend that as if you do so, and one of those orders is completed later on (say due to a customer leaving the payment window open for a long time), the order creation will fail silently, and the customer will have paid and you will never know.