Problem when full payment with user points

  • Posts: 1850
  • Thank you received: 609
  • Hikamarket Multivendor Hikashop Business
3 weeks 13 hours ago #306213

-- HikaShop version -- : 4.0.3
-- Joomla version -- : 3.9.5
-- PHP version -- : 7.2

Hi,

Using HikaShop User Points for the first time, I notice it doesn't behave as expected when an order gets paid in full with points.

So, I'm using the HikaShop User Points plugin for customers to collect points, and the HikaShop User Points payment plugin for them to spend points. Screenshots of relevant configurations attached.

All working fine and as intended if a customer uses his points to partially pay for his order: a coupon gets (auto-)applied, showing in the "footer" of the order in order details, invoice and email, correctly reducing the total amount.

Not so if a customer pays an order in full with points.
1.) Minor but still: frontend, after checkout, a system message appears above the usual generic message. No "userpoints_end.php" page. Would be nice to have a dedicated page there.
2.) The order status is correctly changed to "confirmed", but no order status notification email is being sent (yes, checked the log as well: only "created" mail there). Did I do wrong somewhere in config (can't see where)? Can't imagine customers should be left with the "created" email only.
3.) Order details in frontend and backend, and (PDF) invoice: no coupon or other discount shown; the order appears like any other confirmed order without points used (except for "payment method", of course).

Thank you for some comments and either pointing me to where I have misconfigured or so, or a fix.

Attachments:

Please Log in or Create an account to join the conversation.

  • Posts: 65706
  • Thank you received: 9590
  • MODERATOR
3 weeks 1 hour ago #306216

Hi,

1. That's something we could add yes.

2. That's normal. When you use your points for the payment, the order is directly created with the "confirmed" order status.
It's the same with payment plugins where the credit card form is directly in the checkout of HikaShop as the payment happens just after you click on the finish button and before the order is created.
So the order status notification is not sent as the order status is not changed. However, the order creation notification email is sent and it doesn't tell them that they should pay for their order like it does when the order status is created.

3. When you pay in full with a payment method, be it the user points payment method or another one, it just records the payment method in the order/invoice.
If you don't want to have it appear like that, you can change the "use virtual coupon" setting in your payment method and make sure that you have the user points view added to your checkout workflow in the HikaShop configuration. In that case, the points will be added as "additional fee" to the cart, not as a payment method.

Please Log in or Create an account to join the conversation.

  • Posts: 1850
  • Thank you received: 609
  • Hikamarket Multivendor Hikashop Business
2 weeks 6 days ago #306238

Hi Nicolas,
Thanks for your response.

1.) It'd be great if you could add it, indeed. I suspect it might take a while, or? In that case I might do so myself for the interim.

On the other two points, perhaps I didn't explain well enough... so, please let me add some more:

2.) Sure, it's normal and ok for other payment methods, but IMHO not in case an order is paid for in full with points. Typically, a customer receives a confirmation mail once his order is paid, but not here. If the "created" mail is disabled (like often when only on-line payment methods are in use, to avoid two mails at almost the same time), the customer will not receive any notification at all.
So, let me re-phrase: if you insist on not sending a "confirmed" mail with full points payment, is there a way of tricking HikaShop into sending out the "confirmed" mail if (a) payment method is userpoints, and (b) order is fully paid with points?
Can't be too difficult, and it might be even easier to formulate the condition if the order's total amount were correctly 0.00... which will be the next point:

3.) Sorry, but "use virtual points" doesn't seem to be the proper approach here, as at least in this case customers should be able to decide if the want to use points or not, and I understand that virtual points have other side effects as well which aren't desirable here.

Also, I guess the user points payment method should be able to accommodate the case of full payment, too. After all, it works well and correctly if the order gets paid for in part with points, just not if in full.

For example, this is what it looks like with partial points payment (to keep it simple, I'm leaving tax/shipping/etc off):
Subtotal: 100.00
Coupon: -60.00 (from points used)
Grand total: 40.00
Correct, because the $ revenue will be only 40.00, indeed. Customer, shop owner and accountants are happy.

Same example but fully paid with points results in this -- everywhere = mail, order detail page, invoice:
Subtotal: 100.00
Grand total: 100.00
This is incorrect as it says there's 100.00 revenue, and the customer is receiving an invoice worth 100.00, both of which is actually wrong. Please ask your accountant. The shop owner is forced to manually and separately issue a credit note, actually also send it to the customer. Which is really unnecessary (even more so as it's going well and right with partial points payment!), awkward and, in addition to the extra workload, prone to human error as it may well be forgotten.

Instead, it should correctly be:
Subtotal: 100.00
Coupon: -100.00 (from points used)
Grand total: 0.00

Again, your accountant will be able to confirm, and I'm sure you'll agree.

Provisionally, in case you disagree for some reason and/or prefer shop owners needing to deal with those separate, manual credit notes:
- Could you please point me at where I could correct this myself? I need this to work in about two weeks, if not before...
- Or is there a 3rd-party points system you know of which does this well and correctly out of the box, and doesn't cost much more than HikaShop User Points? ;) ;)

Thanks a ton!

Please Log in or Create an account to join the conversation.

  • Posts: 1850
  • Thank you received: 609
  • Hikamarket Multivendor Hikashop Business
2 weeks 6 days ago #306241

Update:

2. and 3.) Found it!
In plugins/hikashoppayment/userpoints/userpoints.php, in function onBeforeOrderCreate_ClassicalMethod, change

if(($this->payment_params->partialpayment == 1 || $this->payment_params->allowshipping == 0) && ($check !== false && $check > 0) && ($check < $fullOrderPoints) && $userPoints) {
to
if(($this->payment_params->partialpayment == 1 || $this->payment_params->allowshipping == 0) && ($check !== false && $check > 0) && $userPoints) {
Then it works as required also when order getting paid in full with points:
- Coupon is generated worth order grand total. Checkout just like with partial payment (= starting over with step 1).
- All emails are being sent: order "created" (to customer and admin), "confirmed" (to customer), and "payment confirmed" (to admin).
- Display of coupon (= order grand total) and grand total resulting in 0.00 in all emails, order detail page front and backend, and invoice.

Partial points payments are still working fine, of course.

Remaining issue with (only) emails in case of payments with points in full:
- Tax is shown only in payment notification to admin, not in the other three emails. Guess I'll need to take a look at the code there, unless you'd have some quick hint.

However, for above mentioned reasons it would be sure good if you'd confirm and applied the "fix" to the code.

Thanks & regards!

Please Log in or Create an account to join the conversation.

  • Posts: 1850
  • Thank you received: 609
  • Hikamarket Multivendor Hikashop Business
2 weeks 6 days ago #306247

One more update:

4.) I've been trying to fix the "remaining issue" in case of orders fully paid with points (tax missing or weird in emails) by working on the $cartFooters array in the preload code. But no joy, yet.

Here is what I'm getting with default preload code -- all based on 7% tax (namekey "GST"):

- "Created" and "confirmed" notification mails to customer, and "created" mail to admin:
Subtotal: 92.52
Coupon: -99.00
Total: 0.00
Tax missing completely.

- "Payment" notification mail to admin:
Subtotal: 92.52
Coupon: -99.00
TOTAL without GST: -6.48
TOTAL with GST: 0.00
Very weird!

- In any case and in all mails, it should say correctly:
Subtotal: 92.52
GST: 6.48
Coupon: -99.00
Total: 0.00

Getting this done in the preloads seems to be way more complex than anticipated.
Any input or hint from you will be very welcome as I don't expect patches for all mentioned in this thread anytime soon because it does involve some work and testing. But I can see no reason why this shouldn't work correctly, and in the meantime I'll happily continue trying to help myself and then keep an eye on future changelogs.

5.) Had not seen this immediately, but there was a similar issue with the "footer" in the checkout cart: tax was also missing there, obviously due to the $taxes variable and how it's used in following conditions. That I got also fixed myself, so please take this as an "FYI", so it'll be working out of the box one day as well.

Thanks again!

Please Log in or Create an account to join the conversation.

  • Posts: 1850
  • Thank you received: 609
  • Hikamarket Multivendor Hikashop Business
2 weeks 5 days ago #306255

... and yet another update. Well, more of a wrap-up.

Sorry for all the long bla-bla, but since the issue seems to be"new" and I've tried to dig in as I hoped I could get it resolved in the not-so-distant future, I thought I share all my findings here.

So, here we go:

1.) Easy to do, so for now I'm going for DIY.

2.) Small code change, but only the tip of the iceberg: it doesn't solve everything.

3.) Partially solved with the fix of 2., and requiring changes in views, plus in my case also PDF invoice.

4.) Looks like I found a way to fix this issue in the email preloads... of course, several of them, and not all being the same (see above: payment notification to admin is different, obviously). As stated, more complex than anticipated.

5.) Solved in view override.

However, some things fixed, and another one comes up:

6.) Also in the "footer" of the checkout cart, things go haywire if:
- payment of order in full with points (as always in this thread)
- shipping to be included in points payment (as per config)
- there is shipping cost for this order (in this case export... had so far tried free shipping only)

The checkout cart footer then looks like this example:
Subtotal: 35.00
Shipping: 10.00
Coupon: -45.00 (from points used)
Total: 10.00

Not only is the display wrong here... no, the system also insists on these 10.00 to be paid. Aaahhh...!
And fixing this seems to be even more complex.




Bottom line:
After two full days spent on this, getting some of it fixed but no end in sight, I reckon the HikaShop User Points payment plugin in its current state is not fit for full payment of orders with points.
Since points earning is working fine, the HikaShop User Points plugin itself is seemingly not to blame. Hence, it's pointless (pun intended ;)) to consider AltaUserPoints or else.

These things do happen, perhaps as a result of HikaShop's "organic growth" over the years (which is a good thing, generally). Whatever the cause: I'm now giving up trying to fix it, reverse my mods and, as a "workaround", instead try to convince my client to allow only partial payment with points up to a certain percentage of order value... praying that he'll accept and that this will work flawlessly in the system once configured...
Just for the record, I can't see "virtual points" as a valid alternative as this appears to be not the same at all.

Case not closed: of course, it'll be great if it'd work correctly out of the box as configured, incl math and results in checkout once shipping gets involved, and be displayed correctly everywhere.
Seeing how much seems to be involved in a complete fix, I'm pretty sure it can't happen over night. Ok, as far as I'm concerned: better well than rush-rush. So, as said before, I'll keep an eye on future changelogs, hoping that in the meantime my client accepts the "workaround" of limiting points spending.

Thanks for reading and considering, no need for a long reply with detailed explanations or so. Instead keep up your good work on code! :)

Last edit: 2 weeks 5 days ago by lousyfool. Reason: Had forgotten 5.)... plus a typo

Please Log in or Create an account to join the conversation.

  • Posts: 65706
  • Thank you received: 9590
  • MODERATOR
2 weeks 4 days ago #306269

Hi,

I still think you want to look at the "vritual coupon" setting.
The user points view on the checkout will have an option to allow you to use your points or not as long as the "ask for no coupon" setting is activated in the plugin (which is the case, looking at your screenshots).

Changing the code in the plugin like you did would bypass the normal flow of the code and thus you dive in untested grounds. So of course, unexpected problems would happen. I don't recommend going that way.

Regarding the userpoints_end.php view file, we'll add that for the next release. It will be easy to add.

The following user(s) said Thank You: lousyfool

Please Log in or Create an account to join the conversation.

  • Posts: 1850
  • Thank you received: 609
  • Hikamarket Multivendor Hikashop Business
2 weeks 4 days ago #306280

Thank you, Nicolas,

"Untested grounds... unexpected problems..." -- oh yeah, felt like I opened Pandora's Box! :woohoo:
Closed it again, for the time being running with some "maximum percent" set.

No one knows your code better than yourself. So, once I find some time, I'll follow your advice and give "virtual points" a try.

Thanks again.

Please Log in or Create an account to join the conversation.

Time to create page: 0.070 seconds
Powered by Kunena Forum