[SOLVED] No processing fee for remaining amount?

Hi Tuan,

Me again... :whistle:

EB 2.14.5 with deposit activated and 2 payment methods:
- Bank Transfer (no processing fee)
- PayPal (+x% processing fee)

If a user registers choosing Bank Transfer for deposit, and later PayPal for the remaining amount, there's no processing fee added to that remaining PayPal payment.

Is that an oversight at my end (can't find anything in the config, though), or in the code? Not good either way... so, thanks for some help with this.


P.S.: Right now I have no way of testing vice versa = PayPal incl processing fee for deposit, Bank Transfer later. How would that go, does the system "expect" the remaining PayPal processing fee in the second payment as well? Tricky stuff... but neither does the user want to pay more than necessary (or be told by the system he should pay more than due), nor does the site owner want to be left with an amount "missing" in the system...

You are correct. I have addressed this with Tuan already. The initial deposit payment charges the fee correctly, but the remainder does not get the fee. I missed out on a few hundred dollars in fees due to this. I had to go in manually to each registrant and adjust the amount due to include the fee so that when the paid the balance it would have the fee built in. One of the developers tried to make some changes for me to fix this but it only caused more issues in that it would only charge the fee not the amount plus the fee. So in the end I had to manually adjust each registrant and was just out the fees for the the few that slipped through. The deposit system needs a lot of adjustments which hopefully Tuan can make happen for 3.0.

Thanks jkosick, and if only for confirming my worst fears.

That's a big, ugly issue.
Neither can I explain or excuse this to my clients, nor to their customers, nor can I wait for 3.x to be out, "complete", and stable.

Ominously, when clicking the "Make Payment" button in the registration history (index.php?option=com_eventbooking&view=history), the page loading then has "payment-deposit" in its URL, and the <h1> page header also reads "Deposit Payment"...
But it's really the remainder payment, no?

<edit>
And anything remotely related in the backend is also "Deposit" only: a tab for "Deposit Payment Messages" with each and anything referring to "Deposit". Anyone a clue why/what/when/where?
</edit>

Anyway... that's almost peanuts.

Tuan, please help out of this misery:
I have no trouble to display the correct amount incl processing fee on this page.
Nor do I have trouble to fetch the processing fee amount or % from the database anywhere else.
But what do I act on to have the correct amount incl processing fee sent to PayPal?

What. A. Mess.
Tuan, we need you here. This is not about "future feature" or "wishlist". This is about bugs of existing, promoted features that render the system at least partially useless, eventually costing people money, time, and image.

For the sake of simple math, let's say as follows:

• Event ticket cost: $100
• Bank Transfer: no processing fee
• PayPal: 10% payment processing fee
• Deposit: yes, 50%

Case 1:
Should be

• Deposit per Bank Transfer: $50
• Remainder per PayPal: $50 + 10% = $55

Reality:

• EB "forgets" the 10% fee on the remainder.
• Site owner loses payment processing fee.

Case 2:
Should be

• Deposit per PayPal: $50 + 10% = $55
• Remainder per Bank Transfer: $50

Reality:

• EB keeps $50 + 10% = $55 as due in the system.
• $100 + 10% = $110 is wrongly shown everywhere.
• User is asked to pay more than is actually due.

Case 3:

• Deposit per PayPal: $50 + 10% = $55
• User does not finish PayPal deposit payment, but cancels payment transaction on the Paypal page and returns to EB site.

Should be:

• System should cancel the event registration and, obviously, not keep an event registration record or, at the very least, clearly mark it as "cancelled".

Reality:

• The event registration record is kept in the system.
• It doesn't show in user's registration history, but in backend.
• No indication in backend record that it was cancelled, it appears identical with a normal pending registration, just as if it had been made with Bank Transfer and is waiting for deposit payment now.
• At least it doesn't send out payment reminders... phew.

I didn't even try further, it's too frustrating.
I don't even want to talk more about language issues ("deposit" everywhere, incl where it's clearly about "remainder", or user cancelling PayPal remainder payment and being told upon return to EB site "your registration was cancelled"... which is the worst message of all and not true at all).

Deposit feature with mixed payment methods (with/without processing fee) = does not work as it should.
PayPal and cancelled payment = does not work as it should in more than one way.
Any and all of the above should be easily reproducible, not only by us out here in the field, but also by the devs.

Sorry, but where is support when you need it?

Tuan?

With all respect, please give us sometime to look at your questions and answer it. We could not always answer it right away when you post it, sometime, there would be delay, especially when I am now focus working on next major releases of the extension

I spent my full time this afternoon for coding, and then, tonight, after dinner, I will look at support requests and answer it again

Please give me sometime

Regards,

Tuan

OK. So here are my quick answers:

1. Case #3 is actually invalid. If people ignore the payment, Events Booking doesn't treat them as registrants and by default, doesn't show it in Events Booking -> Registrants section. I think you see these records because you set Show Incomplete Payment Registration records config option to Yes. Set it to No with solve this case (and make it less confusing)

2. Case #1 and #2 look like a valid case. I will have to work on and address this bug. It is not a quick/easy fix, so it will take time for fixing it.To be safe,give me this weekend to work on it. On Monday, I will have a version which address this case

So why there bugs are these? It is on-going development. It is not planned for all of these features from the beginning. For example, we didn't have a feature to make payment in second step. After people makes payment using the deposit option, the remaining payment was handled manually

Then recently, I added support for make payment feature and didn't think about this case. Even the payment processing fee feature was not available from beginning, it was added when customers asked for it

It is hard to imagine all of these combination, so issues like this happens. Not many customers using these full combination like this, and that's why no-one except jkosick and you saw this issue so far

I could not say that deposit feature is perfect. It was programmed for basic usage at the beginning and then improved on request. Even after fixing this one, it is still not perfect and takes time to improve.

Tuan

Appreciate your replies... "need a few days" is better than nothing.
Thanks.

Can well imagine how things can get overlooked in a system growing in complexity. But you're the one knowing best how things are interwoven with each other and what's affecting what. If it's the deposit or the processing fee thingy, it's supposed to work. And work together.
So, while your explanation makes sort of sense, it's us out here spending even more accumulated time on it. And eventually $$$... who knows how many others haven't even noticed but lose conversions or fees.

But hey, you know all that. And I'm glad it'll be history early next week.

Back to work.
cảm ơn

Ooops, one more thing:

Tuan Pham Ngoc wrote: Case #3 is actually invalid. If people ignore the payment, Events Booking doesn't treat them as registrants and by default, doesn't show it in Events Booking -> Registrants section. I think you see these records because you set Show Incomplete Payment Registration records config option to Yes. Set it to No with solve this case (and make it less confusing)

Sorry, but I can't let you get away with this.
As stated, the record stays valid in the system, with rows and ticket type quantities in #_eb_registrant_tickets and even with a number in #__eb_registrants in the field "number_registrants", reducing the number of available capacity, or tickets, respectively.

Hiding the record in the backend does not "solve" anything. Just the opposite: even if an admin could tell something is wrong with remaining capacity or the number of available tickets, he could (1) not find and delete the record in the backend without going into config and switching the option back and forth to be able to see it (big no no... not every "admin" should access the config!), and (2), if visible, the record looks like any other pending record there, even when displaying all details... as already stated.

Sorry again: more homework for you, but the way it is it's simply wrong = unacceptable.

No workarounds, please, no "hiding" of crappy data and records. Let's get real, do what the "eb-registration-complete-page" says and cancel = delete the registration record and rows in joined tables. No big deal. The Joomla user account and a CB or whatever profile can remain.

Right now it's a real problem as initially described.

Could you please check it carefully? These kind of records won't reducing the number of available capacity, or tickets, respectively. If someone uses Paypal, and didn't make payment, it won't be counted as registrants, so it won't reduce number of available capacity, or tickets.

There are case which users close browser without making payment, so we could not delete these records

There are case which users make payment, but PayPal failed to notify the system, so the record remain Pending and the config option gives admin a chance to see these record and change status back to Paid to correct the behavior....

So please check it again. If these Pending records reduce the available capacity, let me know and I will fix it. If it doesn't (which is how it is developed and works like that for years), I will leave it as how it is

Tuan