Cancel unpaid orders

Hi,

Yes. HikaShop comes with the "Hikashop Orders Automatic Cancel Plugin" which you can configure via the Joomla plugins manager.
It was made specifically for that purpose.
Also, you'll need to configure your HikaShop cron task in order to use it:
www.hikashop.com/support/documentation/5...ashop-cron-task.html

Hi,

We have a captcha plugin here:
www.hikashop.com/marketplace/product/223...-with-recaptcha.html

However, with AI, captcha are getting less and less useful. On our website, we've switched from ReCaptcha to extensions.joomla.org/extension/ospam-a-not/ a few years back with great results. So that's what I would recommend.

Hi,

I just left the default settings and it works great for us.
Maybe you could try combining it with the recaptcha plugin and see if that helps ?

Hi,

The ReCaptcha plugin also works on the guest form.
And for an order to be made, the user has to be logged in or filled the guest form.
If he's logged in, it means he filled the registration form in the past with the captcha.
So either way, adding the Captcha check will help reduce abuse for new orders.

Hi,

The fact that you're getting orders with a disabled payment method (PaypalExpress) and incomplete customer data despite CAPTCHA protections suggests the bots may be rendering the page to grab the form token and then submitting garbage data programmatically.

A few things to try:

1. Make sure to completely uninstall (not just disable) the PaypalExpress payment plugin if you don't use it, so that it can't be selected at all during checkout.
2. Enable the "Record customers IP" option in HikaShop's configuration (System tab). This will log the IP on each order, making it easier to identify and block the source IPs via your server firewall or .htaccess.
3. If the bot orders all come from specific IP ranges, blocking them at the server level (firewall or .htaccess) will be far more effective than any application-level protection.
4. You can also look into a Web Application Firewall (WAF) like Cloudflare's free plan, which can filter out bot traffic before it even reaches your site.

We'll also look into adding bot detection to the checkout process in a future version.

Hi,

After investigating further, we believe the issue is related to the PayPal Express payment plugin specifically. The checkout process already has bot detection.

Unlike the standard checkout flow, PayPal Express creates orders at the very beginning of the payment process, before the customer completes payment on PayPal's side. That's the goal of PayPal Express: to bypass the normal checkout on your website to simplify the payment process for the customers. This means that bots or automated scripts only need to trigger the "Pay with PayPal Express" button to generate an order, without actually going through the full checkout (no CAPTCHA, no form validation, no address entry).

That would explain both the incomplete customer data and the high volume of orders.

Here is what we recommend:

1. Uninstall (not just disable) the PayPal Express payment plugin entirely if you are not using it. Disabling it prevents customers from selecting it, but the callback URL can technically still receive requests.
2. In your PayPal account, check if there are any IPN or webhook URLs still configured that point to your site. Remove any that reference "paypalexpress" in the URL.
3. Enable the "Record customers IP" option in HikaShop configuration (System tab) so we can verify whether the orders come from a single source or many IPs.

We are also looking into adding additional protections to the PayPal Express plugin for a future version.

Hi,

Where to find the IP addresses:

Once "Record customers IP" is enabled in your HikaShop configuration (System > Configuration, in the order section), the IP address will be recorded for all new orders. You can see it when you open an order in the backend. It is displayed in the order details, at the top of the order form. If you have the geolocation plugin installed and enabled, it will also show the city, state and country associated with that IP.

Note that this only applies to orders created after you enabled the setting. Orders created before that won't have an IP recorded.

If you want to see the IPs in bulk, you can create a mass action on orders to export the order_ip column. Go to System > Mass actions, create a new mass action on orders, and add an export action with the
order_ip field.

Checking PayPal for IPN/webhook URLs:

1. Log into your PayPal account at paypal.com
2. Go to Settings (gear icon) > Seller tools (or Account Settings > Notifications)
3. Look for Instant Payment Notifications (IPN) and check the notification URL configured there. If it points to your website with a path containing "paypalexpress" or "hikashop", that's the one bots are likely hitting.
4. Also check Webhooks in the same section for any URLs pointing to your site.
5. If you see old or unused URLs referencing the PayPal Express plugin, remove them.

Good news about HikaShop 6.4.0:

We just released HikaShop 6.4.0 two days ago, and it includes two fixes specifically for this type of problem with the PayPal Express plugin:

- The PayPal Express payment plugin now blocks known bots from initiating orders via the PayPal Express button.
- The PayPal Express payment plugin now prevents duplicate order creation when the PayPal Express button is clicked multiple times, by detecting if a pending order already exists for the same cart.
www.hikashop.com/home/blog/530-hikashop-6-4-0.html

So I'd recommend updating to HikaShop 6.4.0. That should significantly reduce or eliminate the bot-generated orders you're experiencing, without needing to uninstall the PayPal Express plugin.

In the longer term, you might also consider switching to the PayPal Checkout plugin, which is the newer PayPal integration and creates orders later in the checkout flow.

Hi Harald,

Yes, the period is in seconds and your calculation is correct. However, note that this period setting controls both how often the plugin runs via cron AND the age threshold for orders to cancel. With 864000 seconds, the plugin only runs once every 10 days and cancels orders older than 10 days. You likely want to reduce this period drastically, for example to 86400 (1 day) or even 3600 (1 hour), so that the plugin runs more frequently and catches orders sooner.

Also, the plugin only processes a maximum of 20 orders per cron run. So if you have many orders to cancel, it will take several cron runs to process them all. Another reason to keep the period low.

Finally, make sure that the status of the orders you want to cancel matches the "Order created status" configured in your HikaShop configuration. The plugin only targets orders with that specific status. If your orders are in "Pending" status but the "Order created status" is set to "Created", the plugin will not process them.

German answer:

Hallo Harald,

Ja, der Zeitraum wird in Sekunden angegeben und Ihre Berechnung ist korrekt. Beachten Sie jedoch, dass diese Einstellung sowohl steuert, wie oft das Plugin per Cron ausgeführt wird, ALS AUCH das Alter der Bestellungen, die storniert werden sollen. Mit 864000 Sekunden läuft das Plugin nur alle 10 Tage und storniert Bestellungen, die älter als 10 Tage sind. Sie sollten diesen Zeitraum deutlich reduzieren, zum Beispiel auf 86400 (1 Tag) oder sogar 3600 (1 Stunde), damit das Plugin häufiger läuft und Bestellungen schneller erfasst.

Ausserdem verarbeitet das Plugin pro Cron-Durchlauf maximal 20 Bestellungen. Wenn Sie also viele Bestellungen zu stornieren haben, wird es mehrere Cron-Durchläufe dauern, bis alle verarbeitet sind. Ein weiterer Grund, den Zeitraum niedrig zu halten.

Stellen Sie abschliessend sicher, dass der Status der Bestellungen, die Sie stornieren möchten, mit dem in Ihrer HikaShop-Konfiguration eingestellten "Order created status" übereinstimmt. Das Plugin erfasst nur Bestellungen mit diesem bestimmten Status. Wenn Ihre Bestellungen den Status "Pending" (Ausstehend) haben, der "Order created status" aber auf "Created" (Erstellt) eingestellt ist, wird das Plugin sie nicht verarbeiten.

Hi Harald,

To answer your question: the plugin cancels the 20 oldest orders first (sorted by creation date ascending). So reducing the period temporarily to process the backlog faster is a good idea.

However, the main issue is that the plugin only cancels orders with the "Created" status, which is the status configured as "Order created status" in your HikaShop configuration. Looking at your screenshot, your orders are in "Pending" (Ausstehend) status, which is a different status. That is why the plugin has not cancelled any of them.

The plugin would need to be modified to also target "Pending" orders. I will look into adding a setting for that.

Also, orders are not deleted, they are set to the "Cancelled" status. You can still see them in the backend and change their status back if needed.

German answer:

Hallo Harald,

Zu Ihrer Frage: Das Plugin storniert zuerst die 20 ältesten Bestellungen (sortiert nach Erstellungsdatum aufsteigend). Den Zeitraum vorübergehend zu verkürzen, um den Rückstau schneller abzuarbeiten, ist also eine gute Idee.

Das Hauptproblem ist allerdings, dass das Plugin nur Bestellungen mit dem Status "Created" (Erstellt) storniert, also dem Status, der in Ihrer HikaShop-Konfiguration als "Order created status" eingestellt ist. Wie Ihr Screenshot zeigt, haben Ihre Bestellungen den Status "Pending" (Ausstehend), und das ist ein anderer Status. Deshalb hat das Plugin bisher keine davon storniert.

Das Plugin müsste angepasst werden, um auch "Pending"-Bestellungen zu erfassen. Ich werde prüfen, ob ich dafür eine Einstellung hinzufügen kann.

Ausserdem werden die Bestellungen nicht gelöscht, sondern auf den Status "Storniert" gesetzt. Sie können sie weiterhin im Backend sehen und den Status bei Bedarf wieder ändern.