[Skip to main content](#vessel-content) # Profile for mojweb ## [![mojweb's Avatar](https://www.hikashop.com/media/kunena/core/svg/person.svg)](/forum/user/5128-mojweb "View mojweb's Profile") **[ Offline](/forum/user/5128-mojweb)** - **User Type:** User - **Register Date:** 17 Dec 2011 - **Last login:** 2 weeks 4 days ago - **Time Zone:** UTC +1:00 - **Local Time:** 22:04 - **Posts:** 431 - **Profile views:** 367 - **Thank you received:** 22 - **Gender:** Unknown - **Medals:** Hikashop Business - Posts # mojweb's recent posts (431 messages ) All Since last visit 4 Hours 8 Hours 12 Hours 24 Hours 48 Hours Week Month Year All Since last visit 4 Hours 8 Hours 12 Hours 24 Hours 48 Hours Week Month Year | [ ](#forumbottom) | Subject | Replies / Views | Last Post | [ ](#forumtop) | |---|---|---|---|---| | [](/forum/29-payment-methods/910498-hikashop-stripe-unprocessed-purchases?start=20#373134) | [Hikashop Stripe unprocessed purchases](/forum/29-payment-methods/910498-hikashop-stripe-unprocessed-purchases?start=20#373134 "-- HikaShop version -- : 6.3.0 -- Joomla version -- : 4.4.14 -- PHP version -- : 8.3.3 I use Hikashop Stripe Connect Payment Plugin v1.2.5 for card payments. Payment mode is endpage. Every day at least one order appears that is not processed. Instead of being given the opportunity to enter credit card details, the buyer only receives a notification that the order is being processed. Among the orders, the status of such an order is Created. There is no note in the payment log about any error for these cases. In case of rejections or insufficient balance, the error is normally logged. I have debug enabled in the plugin. Where could the problem be?") Category: [Payment Methods](/forum/29-payment-methods "Discussions about the different payment methods for Hikashop") Topic started 6 months 7 hours ago, by [mojweb](/forum/user/5128-mojweb "View mojweb's Profile") [Last Post](/forum/29-payment-methods/910498-hikashop-stripe-unprocessed-purchases?start=20#373135 "Hi, Thanks, this log is the one that explains it. Look at the two orders: 28449 and 28450 were both confirmed and both served the card page, four seconds apart, for the same amount of 28,80 €. That is the same customer going through the last step of the checkout twice. They paid on the second page, the one their browser ended up on, so 28450 is confirmed and 28449 stays in "Created" forever with no payment against it. Nobody was charged twice, and no card ever reached the first order. The other detail confirms it: there is no "form not rendered" line for the stuck order. Our debug build reports that six seconds after the page loads if the Stripe form is missing, so if Stripe's JavaScript had been blocked in that customer's browser we would see it. Nothing came back, which means that page was gone before six seconds had passed, not that it failed to load. The customer never saw anything wrong, which is why they never reported it. The cause is in HikaShop, not in the Stripe plugin. The order form has a guard against being submitted twice, but one path went around it: when a block of the checkout finishes its own request while the final step is still being processed by the server, it submits the form again directly. Your last step takes a few seconds, since the payment, the shipping and the notifications are all called there, and that is the window where it happens. It fits your "at least one a day" exactly, since it needs that timing to line up. We reproduced it here on a Joomla 6.2 shop by slowing the order creation down on purpose: with the event arriving five seconds into the first submission, two orders are placed for the same amount, seconds apart, exactly as in your log. With the fix, the same test places one. It is fixed for 6.6.0. The second submission is now ignored while the order is being placed. The same change also repairs another thing you may have seen: after placing an order, coming back to the checkout with the browser button left the order button doing nothing at all. I've included the patch in the 6.5.2. Download the install package of HikaShop on our website and install it on yours in order to get the patch.") 2 months 2 weeks ago by [nicolas](/forum/user/63-nicolas "View nicolas's Profile") - [1](/forum/29-payment-methods/910498-hikashop-stripe-unprocessed-purchases?start=0 "Page:1") - [2](/forum/29-payment-methods/910498-hikashop-stripe-unprocessed-purchases?start=20 "Page:2") | Replies:23 Views:1299 | [Last Post](/forum/29-payment-methods/910498-hikashop-stripe-unprocessed-purchases?start=20#373135 "Hi, Thanks, this log is the one that explains it. Look at the two orders: 28449 and 28450 were both confirmed and both served the card page, four seconds apart, for the same amount of 28,80 €. That is the same customer going through the last step of the checkout twice. They paid on the second page, the one their browser ended up on, so 28450 is confirmed and 28449 stays in "Created" forever with no payment against it. Nobody was charged twice, and no card ever reached the first order. The other detail confirms it: there is no "form not rendered" line for the stuck order. Our debug build reports that six seconds after the page loads if the Stripe form is missing, so if Stripe's JavaScript had been blocked in that customer's browser we would see it. Nothing came back, which means that page was gone before six seconds had passed, not that it failed to load. The customer never saw anything wrong, which is why they never reported it. The cause is in HikaShop, not in the Stripe plugin. The order form has a guard against being submitted twice, but one path went around it: when a block of the checkout finishes its own request while the final step is still being processed by the server, it submits the form again directly. Your last step takes a few seconds, since the payment, the shipping and the notifications are all called there, and that is the window where it happens. It fits your "at least one a day" exactly, since it needs that timing to line up. We reproduced it here on a Joomla 6.2 shop by slowing the order creation down on purpose: with the event arriving five seconds into the first submission, two orders are placed for the same amount, seconds apart, exactly as in your log. With the fix, the same test places one. It is fixed for 6.6.0. The second submission is now ignored while the order is being placed. The same change also repairs another thing you may have seen: after placing an order, coming back to the checkout with the browser button left the order button doing nothing at all. I've included the patch in the 6.5.2. Download the install package of HikaShop on our website and install it on yours in order to get the patch.") by [nicolas](/forum/user/63-nicolas "View nicolas's Profile") 2 months 2 weeks ago | | [](/forum/29-payment-methods/910498-hikashop-stripe-unprocessed-purchases#372535) | [Hikashop Stripe unprocessed purchases](/forum/29-payment-methods/910498-hikashop-stripe-unprocessed-purchases#372535 "-- HikaShop version -- : 6.3.0 -- Joomla version -- : 4.4.14 -- PHP version -- : 8.3.3 I use Hikashop Stripe Connect Payment Plugin v1.2.5 for card payments. Payment mode is endpage. Every day at least one order appears that is not processed. Instead of being given the opportunity to enter credit card details, the buyer only receives a notification that the order is being processed. Among the orders, the status of such an order is Created. There is no note in the payment log about any error for these cases. In case of rejections or insufficient balance, the error is normally logged. I have debug enabled in the plugin. Where could the problem be?") Category: [Payment Methods](/forum/29-payment-methods "Discussions about the different payment methods for Hikashop") Topic started 6 months 7 hours ago, by [mojweb](/forum/user/5128-mojweb "View mojweb's Profile") [Last Post](/forum/29-payment-methods/910498-hikashop-stripe-unprocessed-purchases?start=20#373135 "Hi, Thanks, this log is the one that explains it. Look at the two orders: 28449 and 28450 were both confirmed and both served the card page, four seconds apart, for the same amount of 28,80 €. That is the same customer going through the last step of the checkout twice. They paid on the second page, the one their browser ended up on, so 28450 is confirmed and 28449 stays in "Created" forever with no payment against it. Nobody was charged twice, and no card ever reached the first order. The other detail confirms it: there is no "form not rendered" line for the stuck order. Our debug build reports that six seconds after the page loads if the Stripe form is missing, so if Stripe's JavaScript had been blocked in that customer's browser we would see it. Nothing came back, which means that page was gone before six seconds had passed, not that it failed to load. The customer never saw anything wrong, which is why they never reported it. The cause is in HikaShop, not in the Stripe plugin. The order form has a guard against being submitted twice, but one path went around it: when a block of the checkout finishes its own request while the final step is still being processed by the server, it submits the form again directly. Your last step takes a few seconds, since the payment, the shipping and the notifications are all called there, and that is the window where it happens. It fits your "at least one a day" exactly, since it needs that timing to line up. We reproduced it here on a Joomla 6.2 shop by slowing the order creation down on purpose: with the event arriving five seconds into the first submission, two orders are placed for the same amount, seconds apart, exactly as in your log. With the fix, the same test places one. It is fixed for 6.6.0. The second submission is now ignored while the order is being placed. The same change also repairs another thing you may have seen: after placing an order, coming back to the checkout with the browser button left the order button doing nothing at all. I've included the patch in the 6.5.2. Download the install package of HikaShop on our website and install it on yours in order to get the patch.") 2 months 2 weeks ago by [nicolas](/forum/user/63-nicolas "View nicolas's Profile") - [1](/forum/29-payment-methods/910498-hikashop-stripe-unprocessed-purchases?start=0 "Page:1") - [2](/forum/29-payment-methods/910498-hikashop-stripe-unprocessed-purchases?start=20 "Page:2") | Replies:23 Views:1299 | [Last Post](/forum/29-payment-methods/910498-hikashop-stripe-unprocessed-purchases?start=20#373135 "Hi, Thanks, this log is the one that explains it. Look at the two orders: 28449 and 28450 were both confirmed and both served the card page, four seconds apart, for the same amount of 28,80 €. That is the same customer going through the last step of the checkout twice. They paid on the second page, the one their browser ended up on, so 28450 is confirmed and 28449 stays in "Created" forever with no payment against it. Nobody was charged twice, and no card ever reached the first order. The other detail confirms it: there is no "form not rendered" line for the stuck order. Our debug build reports that six seconds after the page loads if the Stripe form is missing, so if Stripe's JavaScript had been blocked in that customer's browser we would see it. Nothing came back, which means that page was gone before six seconds had passed, not that it failed to load. The customer never saw anything wrong, which is why they never reported it. The cause is in HikaShop, not in the Stripe plugin. The order form has a guard against being submitted twice, but one path went around it: when a block of the checkout finishes its own request while the final step is still being processed by the server, it submits the form again directly. Your last step takes a few seconds, since the payment, the shipping and the notifications are all called there, and that is the window where it happens. It fits your "at least one a day" exactly, since it needs that timing to line up. We reproduced it here on a Joomla 6.2 shop by slowing the order creation down on purpose: with the event arriving five seconds into the first submission, two orders are placed for the same amount, seconds apart, exactly as in your log. With the fix, the same test places one. It is fixed for 6.6.0. The second submission is now ignored while the order is being placed. The same change also repairs another thing you may have seen: after placing an order, coming back to the checkout with the browser button left the order button doing nothing at all. I've included the patch in the 6.5.2. Download the install package of HikaShop on our website and install it on yours in order to get the patch.") by [nicolas](/forum/user/63-nicolas "View nicolas's Profile") 2 months 2 weeks ago | | [](/forum/29-payment-methods/910498-hikashop-stripe-unprocessed-purchases#372179) | [Hikashop Stripe unprocessed purchases](/forum/29-payment-methods/910498-hikashop-stripe-unprocessed-purchases#372179 "-- HikaShop version -- : 6.3.0 -- Joomla version -- : 4.4.14 -- PHP version -- : 8.3.3 I use Hikashop Stripe Connect Payment Plugin v1.2.5 for card payments. Payment mode is endpage. Every day at least one order appears that is not processed. Instead of being given the opportunity to enter credit card details, the buyer only receives a notification that the order is being processed. Among the orders, the status of such an order is Created. There is no note in the payment log about any error for these cases. In case of rejections or insufficient balance, the error is normally logged. I have debug enabled in the plugin. Where could the problem be?") Category: [Payment Methods](/forum/29-payment-methods "Discussions about the different payment methods for Hikashop") Topic started 6 months 7 hours ago, by [mojweb](/forum/user/5128-mojweb "View mojweb's Profile") [Last Post](/forum/29-payment-methods/910498-hikashop-stripe-unprocessed-purchases?start=20#373135 "Hi, Thanks, this log is the one that explains it. Look at the two orders: 28449 and 28450 were both confirmed and both served the card page, four seconds apart, for the same amount of 28,80 €. That is the same customer going through the last step of the checkout twice. They paid on the second page, the one their browser ended up on, so 28450 is confirmed and 28449 stays in "Created" forever with no payment against it. Nobody was charged twice, and no card ever reached the first order. The other detail confirms it: there is no "form not rendered" line for the stuck order. Our debug build reports that six seconds after the page loads if the Stripe form is missing, so if Stripe's JavaScript had been blocked in that customer's browser we would see it. Nothing came back, which means that page was gone before six seconds had passed, not that it failed to load. The customer never saw anything wrong, which is why they never reported it. The cause is in HikaShop, not in the Stripe plugin. The order form has a guard against being submitted twice, but one path went around it: when a block of the checkout finishes its own request while the final step is still being processed by the server, it submits the form again directly. Your last step takes a few seconds, since the payment, the shipping and the notifications are all called there, and that is the window where it happens. It fits your "at least one a day" exactly, since it needs that timing to line up. We reproduced it here on a Joomla 6.2 shop by slowing the order creation down on purpose: with the event arriving five seconds into the first submission, two orders are placed for the same amount, seconds apart, exactly as in your log. With the fix, the same test places one. It is fixed for 6.6.0. The second submission is now ignored while the order is being placed. The same change also repairs another thing you may have seen: after placing an order, coming back to the checkout with the browser button left the order button doing nothing at all. I've included the patch in the 6.5.2. Download the install package of HikaShop on our website and install it on yours in order to get the patch.") 2 months 2 weeks ago by [nicolas](/forum/user/63-nicolas "View nicolas's Profile") - [1](/forum/29-payment-methods/910498-hikashop-stripe-unprocessed-purchases?start=0 "Page:1") - [2](/forum/29-payment-methods/910498-hikashop-stripe-unprocessed-purchases?start=20 "Page:2") | Replies:23 Views:1299 | [Last Post](/forum/29-payment-methods/910498-hikashop-stripe-unprocessed-purchases?start=20#373135 "Hi, Thanks, this log is the one that explains it. Look at the two orders: 28449 and 28450 were both confirmed and both served the card page, four seconds apart, for the same amount of 28,80 €. That is the same customer going through the last step of the checkout twice. They paid on the second page, the one their browser ended up on, so 28450 is confirmed and 28449 stays in "Created" forever with no payment against it. Nobody was charged twice, and no card ever reached the first order. The other detail confirms it: there is no "form not rendered" line for the stuck order. Our debug build reports that six seconds after the page loads if the Stripe form is missing, so if Stripe's JavaScript had been blocked in that customer's browser we would see it. Nothing came back, which means that page was gone before six seconds had passed, not that it failed to load. The customer never saw anything wrong, which is why they never reported it. The cause is in HikaShop, not in the Stripe plugin. The order form has a guard against being submitted twice, but one path went around it: when a block of the checkout finishes its own request while the final step is still being processed by the server, it submits the form again directly. Your last step takes a few seconds, since the payment, the shipping and the notifications are all called there, and that is the window where it happens. It fits your "at least one a day" exactly, since it needs that timing to line up. We reproduced it here on a Joomla 6.2 shop by slowing the order creation down on purpose: with the event arriving five seconds into the first submission, two orders are placed for the same amount, seconds apart, exactly as in your log. With the fix, the same test places one. It is fixed for 6.6.0. The second submission is now ignored while the order is being placed. The same change also repairs another thing you may have seen: after placing an order, coming back to the checkout with the browser button left the order button doing nothing at all. I've included the patch in the 6.5.2. Download the install package of HikaShop on our website and install it on yours in order to get the patch.") by [nicolas](/forum/user/63-nicolas "View nicolas's Profile") 2 months 2 weeks ago | | [](/forum/29-payment-methods/910498-hikashop-stripe-unprocessed-purchases#372119) | [Hikashop Stripe unprocessed purchases](/forum/29-payment-methods/910498-hikashop-stripe-unprocessed-purchases#372119 "-- HikaShop version -- : 6.3.0 -- Joomla version -- : 4.4.14 -- PHP version -- : 8.3.3 I use Hikashop Stripe Connect Payment Plugin v1.2.5 for card payments. Payment mode is endpage. Every day at least one order appears that is not processed. Instead of being given the opportunity to enter credit card details, the buyer only receives a notification that the order is being processed. Among the orders, the status of such an order is Created. There is no note in the payment log about any error for these cases. In case of rejections or insufficient balance, the error is normally logged. I have debug enabled in the plugin. Where could the problem be?") Category: [Payment Methods](/forum/29-payment-methods "Discussions about the different payment methods for Hikashop") Topic started 6 months 7 hours ago, by [mojweb](/forum/user/5128-mojweb "View mojweb's Profile") [Last Post](/forum/29-payment-methods/910498-hikashop-stripe-unprocessed-purchases?start=20#373135 "Hi, Thanks, this log is the one that explains it. Look at the two orders: 28449 and 28450 were both confirmed and both served the card page, four seconds apart, for the same amount of 28,80 €. That is the same customer going through the last step of the checkout twice. They paid on the second page, the one their browser ended up on, so 28450 is confirmed and 28449 stays in "Created" forever with no payment against it. Nobody was charged twice, and no card ever reached the first order. The other detail confirms it: there is no "form not rendered" line for the stuck order. Our debug build reports that six seconds after the page loads if the Stripe form is missing, so if Stripe's JavaScript had been blocked in that customer's browser we would see it. Nothing came back, which means that page was gone before six seconds had passed, not that it failed to load. The customer never saw anything wrong, which is why they never reported it. The cause is in HikaShop, not in the Stripe plugin. The order form has a guard against being submitted twice, but one path went around it: when a block of the checkout finishes its own request while the final step is still being processed by the server, it submits the form again directly. Your last step takes a few seconds, since the payment, the shipping and the notifications are all called there, and that is the window where it happens. It fits your "at least one a day" exactly, since it needs that timing to line up. We reproduced it here on a Joomla 6.2 shop by slowing the order creation down on purpose: with the event arriving five seconds into the first submission, two orders are placed for the same amount, seconds apart, exactly as in your log. With the fix, the same test places one. It is fixed for 6.6.0. The second submission is now ignored while the order is being placed. The same change also repairs another thing you may have seen: after placing an order, coming back to the checkout with the browser button left the order button doing nothing at all. I've included the patch in the 6.5.2. Download the install package of HikaShop on our website and install it on yours in order to get the patch.") 2 months 2 weeks ago by [nicolas](/forum/user/63-nicolas "View nicolas's Profile") - [1](/forum/29-payment-methods/910498-hikashop-stripe-unprocessed-purchases?start=0 "Page:1") - [2](/forum/29-payment-methods/910498-hikashop-stripe-unprocessed-purchases?start=20 "Page:2") | Replies:23 Views:1299 | [Last Post](/forum/29-payment-methods/910498-hikashop-stripe-unprocessed-purchases?start=20#373135 "Hi, Thanks, this log is the one that explains it. Look at the two orders: 28449 and 28450 were both confirmed and both served the card page, four seconds apart, for the same amount of 28,80 €. That is the same customer going through the last step of the checkout twice. They paid on the second page, the one their browser ended up on, so 28450 is confirmed and 28449 stays in "Created" forever with no payment against it. Nobody was charged twice, and no card ever reached the first order. The other detail confirms it: there is no "form not rendered" line for the stuck order. Our debug build reports that six seconds after the page loads if the Stripe form is missing, so if Stripe's JavaScript had been blocked in that customer's browser we would see it. Nothing came back, which means that page was gone before six seconds had passed, not that it failed to load. The customer never saw anything wrong, which is why they never reported it. The cause is in HikaShop, not in the Stripe plugin. The order form has a guard against being submitted twice, but one path went around it: when a block of the checkout finishes its own request while the final step is still being processed by the server, it submits the form again directly. Your last step takes a few seconds, since the payment, the shipping and the notifications are all called there, and that is the window where it happens. It fits your "at least one a day" exactly, since it needs that timing to line up. We reproduced it here on a Joomla 6.2 shop by slowing the order creation down on purpose: with the event arriving five seconds into the first submission, two orders are placed for the same amount, seconds apart, exactly as in your log. With the fix, the same test places one. It is fixed for 6.6.0. The second submission is now ignored while the order is being placed. The same change also repairs another thing you may have seen: after placing an order, coming back to the checkout with the browser button left the order button doing nothing at all. I've included the patch in the 6.5.2. Download the install package of HikaShop on our website and install it on yours in order to get the patch.") by [nicolas](/forum/user/63-nicolas "View nicolas's Profile") 2 months 2 weeks ago | | [](/forum/29-payment-methods/910498-hikashop-stripe-unprocessed-purchases#372045) | [Hikashop Stripe unprocessed purchases](/forum/29-payment-methods/910498-hikashop-stripe-unprocessed-purchases#372045 "-- HikaShop version -- : 6.3.0 -- Joomla version -- : 4.4.14 -- PHP version -- : 8.3.3 I use Hikashop Stripe Connect Payment Plugin v1.2.5 for card payments. Payment mode is endpage. Every day at least one order appears that is not processed. Instead of being given the opportunity to enter credit card details, the buyer only receives a notification that the order is being processed. Among the orders, the status of such an order is Created. There is no note in the payment log about any error for these cases. In case of rejections or insufficient balance, the error is normally logged. I have debug enabled in the plugin. Where could the problem be?") Category: [Payment Methods](/forum/29-payment-methods "Discussions about the different payment methods for Hikashop") Topic started 6 months 7 hours ago, by [mojweb](/forum/user/5128-mojweb "View mojweb's Profile") [Last Post](/forum/29-payment-methods/910498-hikashop-stripe-unprocessed-purchases?start=20#373135 "Hi, Thanks, this log is the one that explains it. Look at the two orders: 28449 and 28450 were both confirmed and both served the card page, four seconds apart, for the same amount of 28,80 €. That is the same customer going through the last step of the checkout twice. They paid on the second page, the one their browser ended up on, so 28450 is confirmed and 28449 stays in "Created" forever with no payment against it. Nobody was charged twice, and no card ever reached the first order. The other detail confirms it: there is no "form not rendered" line for the stuck order. Our debug build reports that six seconds after the page loads if the Stripe form is missing, so if Stripe's JavaScript had been blocked in that customer's browser we would see it. Nothing came back, which means that page was gone before six seconds had passed, not that it failed to load. The customer never saw anything wrong, which is why they never reported it. The cause is in HikaShop, not in the Stripe plugin. The order form has a guard against being submitted twice, but one path went around it: when a block of the checkout finishes its own request while the final step is still being processed by the server, it submits the form again directly. Your last step takes a few seconds, since the payment, the shipping and the notifications are all called there, and that is the window where it happens. It fits your "at least one a day" exactly, since it needs that timing to line up. We reproduced it here on a Joomla 6.2 shop by slowing the order creation down on purpose: with the event arriving five seconds into the first submission, two orders are placed for the same amount, seconds apart, exactly as in your log. With the fix, the same test places one. It is fixed for 6.6.0. The second submission is now ignored while the order is being placed. The same change also repairs another thing you may have seen: after placing an order, coming back to the checkout with the browser button left the order button doing nothing at all. I've included the patch in the 6.5.2. Download the install package of HikaShop on our website and install it on yours in order to get the patch.") 2 months 2 weeks ago by [nicolas](/forum/user/63-nicolas "View nicolas's Profile") - [1](/forum/29-payment-methods/910498-hikashop-stripe-unprocessed-purchases?start=0 "Page:1") - [2](/forum/29-payment-methods/910498-hikashop-stripe-unprocessed-purchases?start=20 "Page:2") | Replies:23 Views:1299 | [Last Post](/forum/29-payment-methods/910498-hikashop-stripe-unprocessed-purchases?start=20#373135 "Hi, Thanks, this log is the one that explains it. Look at the two orders: 28449 and 28450 were both confirmed and both served the card page, four seconds apart, for the same amount of 28,80 €. That is the same customer going through the last step of the checkout twice. They paid on the second page, the one their browser ended up on, so 28450 is confirmed and 28449 stays in "Created" forever with no payment against it. Nobody was charged twice, and no card ever reached the first order. The other detail confirms it: there is no "form not rendered" line for the stuck order. Our debug build reports that six seconds after the page loads if the Stripe form is missing, so if Stripe's JavaScript had been blocked in that customer's browser we would see it. Nothing came back, which means that page was gone before six seconds had passed, not that it failed to load. The customer never saw anything wrong, which is why they never reported it. The cause is in HikaShop, not in the Stripe plugin. The order form has a guard against being submitted twice, but one path went around it: when a block of the checkout finishes its own request while the final step is still being processed by the server, it submits the form again directly. Your last step takes a few seconds, since the payment, the shipping and the notifications are all called there, and that is the window where it happens. It fits your "at least one a day" exactly, since it needs that timing to line up. We reproduced it here on a Joomla 6.2 shop by slowing the order creation down on purpose: with the event arriving five seconds into the first submission, two orders are placed for the same amount, seconds apart, exactly as in your log. With the fix, the same test places one. It is fixed for 6.6.0. The second submission is now ignored while the order is being placed. The same change also repairs another thing you may have seen: after placing an order, coming back to the checkout with the browser button left the order button doing nothing at all. I've included the patch in the 6.5.2. Download the install package of HikaShop on our website and install it on yours in order to get the patch.") by [nicolas](/forum/user/63-nicolas "View nicolas's Profile") 2 months 2 weeks ago | | [](/forum/29-payment-methods/910498-hikashop-stripe-unprocessed-purchases#371877) | [Hikashop Stripe unprocessed purchases](/forum/29-payment-methods/910498-hikashop-stripe-unprocessed-purchases#371877 "-- HikaShop version -- : 6.3.0 -- Joomla version -- : 4.4.14 -- PHP version -- : 8.3.3 I use Hikashop Stripe Connect Payment Plugin v1.2.5 for card payments. Payment mode is endpage. Every day at least one order appears that is not processed. Instead of being given the opportunity to enter credit card details, the buyer only receives a notification that the order is being processed. Among the orders, the status of such an order is Created. There is no note in the payment log about any error for these cases. In case of rejections or insufficient balance, the error is normally logged. I have debug enabled in the plugin. Where could the problem be?") Category: [Payment Methods](/forum/29-payment-methods "Discussions about the different payment methods for Hikashop") Topic started 6 months 7 hours ago, by [mojweb](/forum/user/5128-mojweb "View mojweb's Profile") [Last Post](/forum/29-payment-methods/910498-hikashop-stripe-unprocessed-purchases?start=20#373135 "Hi, Thanks, this log is the one that explains it. Look at the two orders: 28449 and 28450 were both confirmed and both served the card page, four seconds apart, for the same amount of 28,80 €. That is the same customer going through the last step of the checkout twice. They paid on the second page, the one their browser ended up on, so 28450 is confirmed and 28449 stays in "Created" forever with no payment against it. Nobody was charged twice, and no card ever reached the first order. The other detail confirms it: there is no "form not rendered" line for the stuck order. Our debug build reports that six seconds after the page loads if the Stripe form is missing, so if Stripe's JavaScript had been blocked in that customer's browser we would see it. Nothing came back, which means that page was gone before six seconds had passed, not that it failed to load. The customer never saw anything wrong, which is why they never reported it. The cause is in HikaShop, not in the Stripe plugin. The order form has a guard against being submitted twice, but one path went around it: when a block of the checkout finishes its own request while the final step is still being processed by the server, it submits the form again directly. Your last step takes a few seconds, since the payment, the shipping and the notifications are all called there, and that is the window where it happens. It fits your "at least one a day" exactly, since it needs that timing to line up. We reproduced it here on a Joomla 6.2 shop by slowing the order creation down on purpose: with the event arriving five seconds into the first submission, two orders are placed for the same amount, seconds apart, exactly as in your log. With the fix, the same test places one. It is fixed for 6.6.0. The second submission is now ignored while the order is being placed. The same change also repairs another thing you may have seen: after placing an order, coming back to the checkout with the browser button left the order button doing nothing at all. I've included the patch in the 6.5.2. Download the install package of HikaShop on our website and install it on yours in order to get the patch.") 2 months 2 weeks ago by [nicolas](/forum/user/63-nicolas "View nicolas's Profile") - [1](/forum/29-payment-methods/910498-hikashop-stripe-unprocessed-purchases?start=0 "Page:1") - [2](/forum/29-payment-methods/910498-hikashop-stripe-unprocessed-purchases?start=20 "Page:2") | Replies:23 Views:1299 | [Last Post](/forum/29-payment-methods/910498-hikashop-stripe-unprocessed-purchases?start=20#373135 "Hi, Thanks, this log is the one that explains it. Look at the two orders: 28449 and 28450 were both confirmed and both served the card page, four seconds apart, for the same amount of 28,80 €. That is the same customer going through the last step of the checkout twice. They paid on the second page, the one their browser ended up on, so 28450 is confirmed and 28449 stays in "Created" forever with no payment against it. Nobody was charged twice, and no card ever reached the first order. The other detail confirms it: there is no "form not rendered" line for the stuck order. Our debug build reports that six seconds after the page loads if the Stripe form is missing, so if Stripe's JavaScript had been blocked in that customer's browser we would see it. Nothing came back, which means that page was gone before six seconds had passed, not that it failed to load. The customer never saw anything wrong, which is why they never reported it. The cause is in HikaShop, not in the Stripe plugin. The order form has a guard against being submitted twice, but one path went around it: when a block of the checkout finishes its own request while the final step is still being processed by the server, it submits the form again directly. Your last step takes a few seconds, since the payment, the shipping and the notifications are all called there, and that is the window where it happens. It fits your "at least one a day" exactly, since it needs that timing to line up. We reproduced it here on a Joomla 6.2 shop by slowing the order creation down on purpose: with the event arriving five seconds into the first submission, two orders are placed for the same amount, seconds apart, exactly as in your log. With the fix, the same test places one. It is fixed for 6.6.0. The second submission is now ignored while the order is being placed. The same change also repairs another thing you may have seen: after placing an order, coming back to the checkout with the browser button left the order button doing nothing at all. I've included the patch in the 6.5.2. Download the install package of HikaShop on our website and install it on yours in order to get the patch.") by [nicolas](/forum/user/63-nicolas "View nicolas's Profile") 2 months 2 weeks ago | | [](/forum/29-payment-methods/910498-hikashop-stripe-unprocessed-purchases#371869) | [Hikashop Stripe unprocessed purchases](/forum/29-payment-methods/910498-hikashop-stripe-unprocessed-purchases#371869 "-- HikaShop version -- : 6.3.0 -- Joomla version -- : 4.4.14 -- PHP version -- : 8.3.3 I use Hikashop Stripe Connect Payment Plugin v1.2.5 for card payments. Payment mode is endpage. Every day at least one order appears that is not processed. Instead of being given the opportunity to enter credit card details, the buyer only receives a notification that the order is being processed. Among the orders, the status of such an order is Created. There is no note in the payment log about any error for these cases. In case of rejections or insufficient balance, the error is normally logged. I have debug enabled in the plugin. Where could the problem be?") Category: [Payment Methods](/forum/29-payment-methods "Discussions about the different payment methods for Hikashop") Topic started 6 months 7 hours ago, by [mojweb](/forum/user/5128-mojweb "View mojweb's Profile") [Last Post](/forum/29-payment-methods/910498-hikashop-stripe-unprocessed-purchases?start=20#373135 "Hi, Thanks, this log is the one that explains it. Look at the two orders: 28449 and 28450 were both confirmed and both served the card page, four seconds apart, for the same amount of 28,80 €. That is the same customer going through the last step of the checkout twice. They paid on the second page, the one their browser ended up on, so 28450 is confirmed and 28449 stays in "Created" forever with no payment against it. Nobody was charged twice, and no card ever reached the first order. The other detail confirms it: there is no "form not rendered" line for the stuck order. Our debug build reports that six seconds after the page loads if the Stripe form is missing, so if Stripe's JavaScript had been blocked in that customer's browser we would see it. Nothing came back, which means that page was gone before six seconds had passed, not that it failed to load. The customer never saw anything wrong, which is why they never reported it. The cause is in HikaShop, not in the Stripe plugin. The order form has a guard against being submitted twice, but one path went around it: when a block of the checkout finishes its own request while the final step is still being processed by the server, it submits the form again directly. Your last step takes a few seconds, since the payment, the shipping and the notifications are all called there, and that is the window where it happens. It fits your "at least one a day" exactly, since it needs that timing to line up. We reproduced it here on a Joomla 6.2 shop by slowing the order creation down on purpose: with the event arriving five seconds into the first submission, two orders are placed for the same amount, seconds apart, exactly as in your log. With the fix, the same test places one. It is fixed for 6.6.0. The second submission is now ignored while the order is being placed. The same change also repairs another thing you may have seen: after placing an order, coming back to the checkout with the browser button left the order button doing nothing at all. I've included the patch in the 6.5.2. Download the install package of HikaShop on our website and install it on yours in order to get the patch.") 2 months 2 weeks ago by [nicolas](/forum/user/63-nicolas "View nicolas's Profile") - [1](/forum/29-payment-methods/910498-hikashop-stripe-unprocessed-purchases?start=0 "Page:1") - [2](/forum/29-payment-methods/910498-hikashop-stripe-unprocessed-purchases?start=20 "Page:2") | Replies:23 Views:1299 | [Last Post](/forum/29-payment-methods/910498-hikashop-stripe-unprocessed-purchases?start=20#373135 "Hi, Thanks, this log is the one that explains it. Look at the two orders: 28449 and 28450 were both confirmed and both served the card page, four seconds apart, for the same amount of 28,80 €. That is the same customer going through the last step of the checkout twice. They paid on the second page, the one their browser ended up on, so 28450 is confirmed and 28449 stays in "Created" forever with no payment against it. Nobody was charged twice, and no card ever reached the first order. The other detail confirms it: there is no "form not rendered" line for the stuck order. Our debug build reports that six seconds after the page loads if the Stripe form is missing, so if Stripe's JavaScript had been blocked in that customer's browser we would see it. Nothing came back, which means that page was gone before six seconds had passed, not that it failed to load. The customer never saw anything wrong, which is why they never reported it. The cause is in HikaShop, not in the Stripe plugin. The order form has a guard against being submitted twice, but one path went around it: when a block of the checkout finishes its own request while the final step is still being processed by the server, it submits the form again directly. Your last step takes a few seconds, since the payment, the shipping and the notifications are all called there, and that is the window where it happens. It fits your "at least one a day" exactly, since it needs that timing to line up. We reproduced it here on a Joomla 6.2 shop by slowing the order creation down on purpose: with the event arriving five seconds into the first submission, two orders are placed for the same amount, seconds apart, exactly as in your log. With the fix, the same test places one. It is fixed for 6.6.0. The second submission is now ignored while the order is being placed. The same change also repairs another thing you may have seen: after placing an order, coming back to the checkout with the browser button left the order button doing nothing at all. I've included the patch in the 6.5.2. Download the install package of HikaShop on our website and install it on yours in order to get the patch.") by [nicolas](/forum/user/63-nicolas "View nicolas's Profile") 2 months 2 weeks ago | | [](/forum/29-payment-methods/910498-hikashop-stripe-unprocessed-purchases#371797) | [Hikashop Stripe unprocessed purchases](/forum/29-payment-methods/910498-hikashop-stripe-unprocessed-purchases#371797 "-- HikaShop version -- : 6.3.0 -- Joomla version -- : 4.4.14 -- PHP version -- : 8.3.3 I use Hikashop Stripe Connect Payment Plugin v1.2.5 for card payments. Payment mode is endpage. Every day at least one order appears that is not processed. Instead of being given the opportunity to enter credit card details, the buyer only receives a notification that the order is being processed. Among the orders, the status of such an order is Created. There is no note in the payment log about any error for these cases. In case of rejections or insufficient balance, the error is normally logged. I have debug enabled in the plugin. Where could the problem be?") Category: [Payment Methods](/forum/29-payment-methods "Discussions about the different payment methods for Hikashop") Topic started 6 months 7 hours ago, by [mojweb](/forum/user/5128-mojweb "View mojweb's Profile") [Last Post](/forum/29-payment-methods/910498-hikashop-stripe-unprocessed-purchases?start=20#373135 "Hi, Thanks, this log is the one that explains it. Look at the two orders: 28449 and 28450 were both confirmed and both served the card page, four seconds apart, for the same amount of 28,80 €. That is the same customer going through the last step of the checkout twice. They paid on the second page, the one their browser ended up on, so 28450 is confirmed and 28449 stays in "Created" forever with no payment against it. Nobody was charged twice, and no card ever reached the first order. The other detail confirms it: there is no "form not rendered" line for the stuck order. Our debug build reports that six seconds after the page loads if the Stripe form is missing, so if Stripe's JavaScript had been blocked in that customer's browser we would see it. Nothing came back, which means that page was gone before six seconds had passed, not that it failed to load. The customer never saw anything wrong, which is why they never reported it. The cause is in HikaShop, not in the Stripe plugin. The order form has a guard against being submitted twice, but one path went around it: when a block of the checkout finishes its own request while the final step is still being processed by the server, it submits the form again directly. Your last step takes a few seconds, since the payment, the shipping and the notifications are all called there, and that is the window where it happens. It fits your "at least one a day" exactly, since it needs that timing to line up. We reproduced it here on a Joomla 6.2 shop by slowing the order creation down on purpose: with the event arriving five seconds into the first submission, two orders are placed for the same amount, seconds apart, exactly as in your log. With the fix, the same test places one. It is fixed for 6.6.0. The second submission is now ignored while the order is being placed. The same change also repairs another thing you may have seen: after placing an order, coming back to the checkout with the browser button left the order button doing nothing at all. I've included the patch in the 6.5.2. Download the install package of HikaShop on our website and install it on yours in order to get the patch.") 2 months 2 weeks ago by [nicolas](/forum/user/63-nicolas "View nicolas's Profile") - [1](/forum/29-payment-methods/910498-hikashop-stripe-unprocessed-purchases?start=0 "Page:1") - [2](/forum/29-payment-methods/910498-hikashop-stripe-unprocessed-purchases?start=20 "Page:2") | Replies:23 Views:1299 | [Last Post](/forum/29-payment-methods/910498-hikashop-stripe-unprocessed-purchases?start=20#373135 "Hi, Thanks, this log is the one that explains it. Look at the two orders: 28449 and 28450 were both confirmed and both served the card page, four seconds apart, for the same amount of 28,80 €. That is the same customer going through the last step of the checkout twice. They paid on the second page, the one their browser ended up on, so 28450 is confirmed and 28449 stays in "Created" forever with no payment against it. Nobody was charged twice, and no card ever reached the first order. The other detail confirms it: there is no "form not rendered" line for the stuck order. Our debug build reports that six seconds after the page loads if the Stripe form is missing, so if Stripe's JavaScript had been blocked in that customer's browser we would see it. Nothing came back, which means that page was gone before six seconds had passed, not that it failed to load. The customer never saw anything wrong, which is why they never reported it. The cause is in HikaShop, not in the Stripe plugin. The order form has a guard against being submitted twice, but one path went around it: when a block of the checkout finishes its own request while the final step is still being processed by the server, it submits the form again directly. Your last step takes a few seconds, since the payment, the shipping and the notifications are all called there, and that is the window where it happens. It fits your "at least one a day" exactly, since it needs that timing to line up. We reproduced it here on a Joomla 6.2 shop by slowing the order creation down on purpose: with the event arriving five seconds into the first submission, two orders are placed for the same amount, seconds apart, exactly as in your log. With the fix, the same test places one. It is fixed for 6.6.0. The second submission is now ignored while the order is being placed. The same change also repairs another thing you may have seen: after placing an order, coming back to the checkout with the browser button left the order button doing nothing at all. I've included the patch in the 6.5.2. Download the install package of HikaShop on our website and install it on yours in order to get the patch.") by [nicolas](/forum/user/63-nicolas "View nicolas's Profile") 2 months 2 weeks ago | | [](/forum/29-payment-methods/910498-hikashop-stripe-unprocessed-purchases#371787) | [Hikashop Stripe unprocessed purchases](/forum/29-payment-methods/910498-hikashop-stripe-unprocessed-purchases#371787 "-- HikaShop version -- : 6.3.0 -- Joomla version -- : 4.4.14 -- PHP version -- : 8.3.3 I use Hikashop Stripe Connect Payment Plugin v1.2.5 for card payments. Payment mode is endpage. Every day at least one order appears that is not processed. Instead of being given the opportunity to enter credit card details, the buyer only receives a notification that the order is being processed. Among the orders, the status of such an order is Created. There is no note in the payment log about any error for these cases. In case of rejections or insufficient balance, the error is normally logged. I have debug enabled in the plugin. Where could the problem be?") Category: [Payment Methods](/forum/29-payment-methods "Discussions about the different payment methods for Hikashop") Topic started 6 months 7 hours ago, by [mojweb](/forum/user/5128-mojweb "View mojweb's Profile") [Last Post](/forum/29-payment-methods/910498-hikashop-stripe-unprocessed-purchases?start=20#373135 "Hi, Thanks, this log is the one that explains it. Look at the two orders: 28449 and 28450 were both confirmed and both served the card page, four seconds apart, for the same amount of 28,80 €. That is the same customer going through the last step of the checkout twice. They paid on the second page, the one their browser ended up on, so 28450 is confirmed and 28449 stays in "Created" forever with no payment against it. Nobody was charged twice, and no card ever reached the first order. The other detail confirms it: there is no "form not rendered" line for the stuck order. Our debug build reports that six seconds after the page loads if the Stripe form is missing, so if Stripe's JavaScript had been blocked in that customer's browser we would see it. Nothing came back, which means that page was gone before six seconds had passed, not that it failed to load. The customer never saw anything wrong, which is why they never reported it. The cause is in HikaShop, not in the Stripe plugin. The order form has a guard against being submitted twice, but one path went around it: when a block of the checkout finishes its own request while the final step is still being processed by the server, it submits the form again directly. Your last step takes a few seconds, since the payment, the shipping and the notifications are all called there, and that is the window where it happens. It fits your "at least one a day" exactly, since it needs that timing to line up. We reproduced it here on a Joomla 6.2 shop by slowing the order creation down on purpose: with the event arriving five seconds into the first submission, two orders are placed for the same amount, seconds apart, exactly as in your log. With the fix, the same test places one. It is fixed for 6.6.0. The second submission is now ignored while the order is being placed. The same change also repairs another thing you may have seen: after placing an order, coming back to the checkout with the browser button left the order button doing nothing at all. I've included the patch in the 6.5.2. Download the install package of HikaShop on our website and install it on yours in order to get the patch.") 2 months 2 weeks ago by [nicolas](/forum/user/63-nicolas "View nicolas's Profile") - [1](/forum/29-payment-methods/910498-hikashop-stripe-unprocessed-purchases?start=0 "Page:1") - [2](/forum/29-payment-methods/910498-hikashop-stripe-unprocessed-purchases?start=20 "Page:2") | Replies:23 Views:1299 | [Last Post](/forum/29-payment-methods/910498-hikashop-stripe-unprocessed-purchases?start=20#373135 "Hi, Thanks, this log is the one that explains it. Look at the two orders: 28449 and 28450 were both confirmed and both served the card page, four seconds apart, for the same amount of 28,80 €. That is the same customer going through the last step of the checkout twice. They paid on the second page, the one their browser ended up on, so 28450 is confirmed and 28449 stays in "Created" forever with no payment against it. Nobody was charged twice, and no card ever reached the first order. The other detail confirms it: there is no "form not rendered" line for the stuck order. Our debug build reports that six seconds after the page loads if the Stripe form is missing, so if Stripe's JavaScript had been blocked in that customer's browser we would see it. Nothing came back, which means that page was gone before six seconds had passed, not that it failed to load. The customer never saw anything wrong, which is why they never reported it. The cause is in HikaShop, not in the Stripe plugin. The order form has a guard against being submitted twice, but one path went around it: when a block of the checkout finishes its own request while the final step is still being processed by the server, it submits the form again directly. Your last step takes a few seconds, since the payment, the shipping and the notifications are all called there, and that is the window where it happens. It fits your "at least one a day" exactly, since it needs that timing to line up. We reproduced it here on a Joomla 6.2 shop by slowing the order creation down on purpose: with the event arriving five seconds into the first submission, two orders are placed for the same amount, seconds apart, exactly as in your log. With the fix, the same test places one. It is fixed for 6.6.0. The second submission is now ignored while the order is being placed. The same change also repairs another thing you may have seen: after placing an order, coming back to the checkout with the browser button left the order button doing nothing at all. I've included the patch in the 6.5.2. Download the install package of HikaShop on our website and install it on yours in order to get the patch.") by [nicolas](/forum/user/63-nicolas "View nicolas's Profile") 2 months 2 weeks ago | | [](/forum/29-payment-methods/910498-hikashop-stripe-unprocessed-purchases#371785) | [Hikashop Stripe unprocessed purchases](/forum/29-payment-methods/910498-hikashop-stripe-unprocessed-purchases#371785 "-- HikaShop version -- : 6.3.0 -- Joomla version -- : 4.4.14 -- PHP version -- : 8.3.3 I use Hikashop Stripe Connect Payment Plugin v1.2.5 for card payments. Payment mode is endpage. Every day at least one order appears that is not processed. Instead of being given the opportunity to enter credit card details, the buyer only receives a notification that the order is being processed. Among the orders, the status of such an order is Created. There is no note in the payment log about any error for these cases. In case of rejections or insufficient balance, the error is normally logged. I have debug enabled in the plugin. Where could the problem be?") Category: [Payment Methods](/forum/29-payment-methods "Discussions about the different payment methods for Hikashop") Topic started 6 months 7 hours ago, by [mojweb](/forum/user/5128-mojweb "View mojweb's Profile") [Last Post](/forum/29-payment-methods/910498-hikashop-stripe-unprocessed-purchases?start=20#373135 "Hi, Thanks, this log is the one that explains it. Look at the two orders: 28449 and 28450 were both confirmed and both served the card page, four seconds apart, for the same amount of 28,80 €. That is the same customer going through the last step of the checkout twice. They paid on the second page, the one their browser ended up on, so 28450 is confirmed and 28449 stays in "Created" forever with no payment against it. Nobody was charged twice, and no card ever reached the first order. The other detail confirms it: there is no "form not rendered" line for the stuck order. Our debug build reports that six seconds after the page loads if the Stripe form is missing, so if Stripe's JavaScript had been blocked in that customer's browser we would see it. Nothing came back, which means that page was gone before six seconds had passed, not that it failed to load. The customer never saw anything wrong, which is why they never reported it. The cause is in HikaShop, not in the Stripe plugin. The order form has a guard against being submitted twice, but one path went around it: when a block of the checkout finishes its own request while the final step is still being processed by the server, it submits the form again directly. Your last step takes a few seconds, since the payment, the shipping and the notifications are all called there, and that is the window where it happens. It fits your "at least one a day" exactly, since it needs that timing to line up. We reproduced it here on a Joomla 6.2 shop by slowing the order creation down on purpose: with the event arriving five seconds into the first submission, two orders are placed for the same amount, seconds apart, exactly as in your log. With the fix, the same test places one. It is fixed for 6.6.0. The second submission is now ignored while the order is being placed. The same change also repairs another thing you may have seen: after placing an order, coming back to the checkout with the browser button left the order button doing nothing at all. I've included the patch in the 6.5.2. Download the install package of HikaShop on our website and install it on yours in order to get the patch.") 2 months 2 weeks ago by [nicolas](/forum/user/63-nicolas "View nicolas's Profile") - [1](/forum/29-payment-methods/910498-hikashop-stripe-unprocessed-purchases?start=0 "Page:1") - [2](/forum/29-payment-methods/910498-hikashop-stripe-unprocessed-purchases?start=20 "Page:2") | Replies:23 Views:1299 | [Last Post](/forum/29-payment-methods/910498-hikashop-stripe-unprocessed-purchases?start=20#373135 "Hi, Thanks, this log is the one that explains it. Look at the two orders: 28449 and 28450 were both confirmed and both served the card page, four seconds apart, for the same amount of 28,80 €. That is the same customer going through the last step of the checkout twice. They paid on the second page, the one their browser ended up on, so 28450 is confirmed and 28449 stays in "Created" forever with no payment against it. Nobody was charged twice, and no card ever reached the first order. The other detail confirms it: there is no "form not rendered" line for the stuck order. Our debug build reports that six seconds after the page loads if the Stripe form is missing, so if Stripe's JavaScript had been blocked in that customer's browser we would see it. Nothing came back, which means that page was gone before six seconds had passed, not that it failed to load. The customer never saw anything wrong, which is why they never reported it. The cause is in HikaShop, not in the Stripe plugin. The order form has a guard against being submitted twice, but one path went around it: when a block of the checkout finishes its own request while the final step is still being processed by the server, it submits the form again directly. Your last step takes a few seconds, since the payment, the shipping and the notifications are all called there, and that is the window where it happens. It fits your "at least one a day" exactly, since it needs that timing to line up. We reproduced it here on a Joomla 6.2 shop by slowing the order creation down on purpose: with the event arriving five seconds into the first submission, two orders are placed for the same amount, seconds apart, exactly as in your log. With the fix, the same test places one. It is fixed for 6.6.0. The second submission is now ignored while the order is being placed. The same change also repairs another thing you may have seen: after placing an order, coming back to the checkout with the browser button left the order button doing nothing at all. I've included the patch in the 6.5.2. Download the install package of HikaShop on our website and install it on yours in order to get the patch.") by [nicolas](/forum/user/63-nicolas "View nicolas's Profile") 2 months 2 weeks ago | [](/forum/topics/feed/mode-topics?format=feed&type=rss) Time to create page: 0.092 seconds [Powered by](/forum/credits) [Kunena Forum](https://www.kunena.org)