Sounds great, but (not to put too much of a damper on it / or maybe I missed something) .. without an integration to the platform (e.g. Lightspeed in my case) it can’t actually be used. And also the other option (list of preset discount codes) is of very limited use, because (at least for me) the discount code needs to have a limited time of validity, starting from the moment when the customer clicks it.
Hi there, @Tanya_FX ![]()
Thanks a bunch for the feedback!
You need the Lightspeed integration to pull the coupons from Lightspeed to the widget to enable coupon validation and validation time limit, am I right?
Hi Max,
Little bit more complicated, I think.
In both options (generated or a list) there needs to be a connection to the platform, for us that is Lightspeed. Without any interfacing the discount code would stand on its own in the widget and is of no use I am afraid. IMHO that was also the gist of the person that made this request. I was very interested to see how you would pull this off as this would require an active integration of Elfsight into platforms like Lightspeed.
See below explained per option.
Option 1 (when the discount code has been generated from the Elfsight widget).
- The generated discount code needs to be pushed to Lightspeed for creation. And preferably with added attributes, like e.g. amount or percentage, valid time, usage limit (fixed to 1), categories and spending offset.
Option 2 (when the discount code has been used from a list as generated beforehand in Lightspeed).
- In this case the discount code(s) has/have been created in Lightspeed and already with the desired attributes, like e.g. apply before tax, category and such.
(- Starting date can be either preset by us, or can be set by the widget when the customer clicked.) - The widget should now set an enddate to the code to limit the valid time. E.g. 3 days from the moment the customer clicked.
See below an example of a discount code.
Got it, thanks a lot for the detailed explanation!
At the moment, it’s impossible to implement this use case. However, this idea sounds interesting and I’ve moved to a separate request. If more users get interested in this feature, we’ll try to consider it in the future updates ![]()
