Hi,
1. You could create a product mass action with a trigger "every hour", a filter product_quantity = 0 and an action "run MySQL query" with a query like this:
UPDATE #__hikashop_product SET product_sale_start=CURRENT_TIMESTAMP()+1209600 WHERE product_id = {product_id} AND product_sale_start < 1
where 1209600 is the number of seconds in 2 weeks.
Once you've configured your cron task (
www.hikashop.com/support/documentation/5...ashop-cron-task.html
), HikaShop will run this mass action once every hour. And when it finds a product with a stock at 0 and without a "sale start date" set, it will set its sale start date to 2 weeks into the future.
That way, on the frontend, the users will see a message like "the product will be sold starting on the 2024/04/17". And you can customize it with a translation override (
www.hikashop.com/download/languages.html#modify
) to say what you want like "the product is being lent to someone at the moment. It is expected to be returned on the 2024/04/17 at the latest".
When the product is returned, you can just set back the stock to 1 and empty the "sale start date" in the product.
2. You could create an order mass action with a trigger "every hour", a filter order_invoice_created >= {time}+1036800 and an action "send an email". In the email address field of the action you can enter user.user_email and it will send the email to the user of the order.
In the subject and body fields of the email, you can use tags like {order_number} or {order_invoice_number}
Note however that you don't have access to the data of the products of the order. That would require some development work to customize the mass action email via the System>Emails menu of HikaShop. But I suppose that you could just write a generic text like :
Please note that you only have 2 days left to return the products you borrowed with the order {order_number}
3. You would have to do this via your Stripe merchant interface.
4. There is one big caveat with what you want to do:
Normally, a payment gateway gets a commission on a payment. And if you refund the payment, the commission fee is returned to you. This means that the payment gateway didn't make any money on the process. Worst, they lost money because they still had to pay for the transaction and the refund to be processed on the banks networks.
I doubt that it will sit well with Stripe that you refund all the payments made by your users and they'll probably make you stop after a while, once they detect the anomaly.
A payment is actually done in two steps:
- first, the payment gateway asks the bank if the transaction is possible and the bank reserves the funds. This is called "authorize"
- second, the payment gateway "capture" the amount made available by the "authorize".
A transaction can usually stay "authorized" for a few weeks before it is cancelled or captured.
This is what is used by car rental companies : they authorize something like 500€ on your card when you get the rental. When you give back the car, the authorization is cancelled, or if there was a problem some of the money or all of the money will be captured.
Stripe has that capability:
docs.stripe.com/payments/extended-authorization
However, it requires passing extra parameters when processing the payment. So it would require contacting the developer of the Stripe payment plugin to have him work on it to add that capability as an extra option:
obsi.dev/