Support

April 30, 2019 at 4:06 am

Hi there,

Did the payment show up as 2 separate payments in Stripe, or a single payment at twice the cost?

Can you set the registration you’ve cancelled back to Approved and post a screenshot fo the transaction screen then, please?

May 1, 2019 at 7:22 am

Thanks for the reply. To answer your question, the transaction came through stripe as one payment instead of two:

Ok, so as far as I can tell, they weren’t ‘double charged’, they had 2 registrations in the cart and were charged for both of those tickets. I say that because:

Registration Screen Shot:
https://www.evernote.com/l/APdT3WvC0vxBWLR1YW3-fTdxaH2ZW-QLiSM

It shows 2 registrations within a group, so they would be charged for both tickets.

Now I’m not saying that’s what the user expected because apparently, it’s not, but so far based on the screenshots EE has 2 registrations and so charged for 2 registrations.

You have multi-event registration enabled on your site, meaning the user can add multiple tickets to a cart and as your only requesting info for the ‘primary registrant’ on the events I test, it’s possible the selection of 2 tickets was overlooked.

I have a customer who purchased 3 tickets. Two in one transaction and one in another.

The admin shows 4 transactions, one canceled.

Whilst I’m not trying to be nit-picky, the admin shows 4 registrations across 3 transactions.

2 registrations assigned to 1 transaction.
1 registration assigned to another transaction.
1 registration assigned to another transaction.

It’s important not to confuse registrations with transactions.

So I have a few questions regarding this screenshot. Why are some showing Not Approved when the transaction was approved?

We’ve seen that happen with caching enabled on the site if you haven’t excluded EE’s pages but it can also happen if there is an error thrown during the request to complete the payment and redirect the user to the thank you page.

Can you check the servers error logs around the same time that payment was made, see any errors there?

So what happens when someone decides to cancel their registration (I have a wait list using your plugin). Does the person who is next automatically get a email that a spot has opened up? Or will the extra ticket go to the extra person (which the user should have been able to fill his spot if it wasn’t for the issue). I want to make sure this user, who already paid for their spot, gets one.

Normally when a space becomes available the next waitlist registration is set to pending payment and an email is sent to them, if you cancel a registration now, you should not actually have a ‘space’ because qty == sold so no-one should get any email unless you then cancel another.

Here is the transaction page:
https://www.evernote.com/l/APdy8AU988dHDZTECKs2BMgNuFmUqjelM-I

Here is the registration:
https://www.evernote.com/l/APfbKj0Ir4JPIpIkmFVlfpSqaziRwxBuz7Y

Again, please not I changed the status to approved instead of the initial which was Pending.

The line items are missing from that transaction, notice how it shows as overpaid, that’s because the payment has no line items to apply to.

Again that can also be caused by caching, are you running any caching plugins on the site or server side caching?

May 2, 2019 at 3:42 am

I should have mentioned that the user can only add one ticket per event. So they can only be charged for one, and as per the transaction, they got charged twice for the same ticket, which is why it shows two registrations. That is the core issue, they got charged twice when the user is unable to select two.

The user can actually order as many tickets for your events as they wish, they would need to add them in singles but there is nothing stopping them from adding the same ticket more than once. I tested this on your site before I replied.

You can try this yourself by selecting a ticket on an event, then when the modal is displayed, click the X on the top right – https://monosnap.com/file/JwyhrAYUUSVd9zBvsA4pYjMPLNizrO

Now select a ticket again and select view cart, another ticket will be added to the cart and the model displayed. Now you have 2 tickets in the cart which creates 2 registrations, it’s not an overcharge or a mistake, EE has 2 tickets so it charges for 2 tickets.

There are 2 registrations on the transaction and the only way for that to happen is if 2 tickets were added to the cart.

Thats exactly the issue. The user did:
1- One transaction, two registrations
2- An additional transaction, one registration.

There should be 3 total, instead, there are 4. As you can see from the Stripe account here:

https://www.evernote.com/l/APcbT4snoxJJi4Fw4FUQDm-J-ARYJPVGms0

This is incorrect.

As mentioned above registrations are only created if the user adds a ticket to the cart, the ‘duplicate’ registration you are referring to is not a duplicate, its another registration, EE can’t just duplicate registrations like that.

There is, however, something strange happening as EE doesn’t add cancelled registrations. There wouldn’t be a point in EE creating a cancelled registration as its, well, cancelled.

Did an admin cancel that registration? Is there a payment assigned to that cancelled registration?

In both cases, it shows both as overpayments.
https://www.evernote.com/l/APdy8AU988dHDZTECKs2BMgNuFmUqjelM-I

In both case? That’s showing Transaction 172 so may I ask which cases you mean?

There is no caching plugin installed on the website. It is hosted on a VPS server.

So no caching on the server side? You can have caching enabled on the VPS itself.

I’m assuming your managing the server yourself?

So since there is no line item to apply payments to:
What can we do when we come across this issue to apply proper payments/refunds when it shows overpayment and no line item (its happened twice so far).

You should not have transactions without line items so you may need to create the registrations so the line items are setup correctly.

First, if you use 4.9.80.p and view the transaction above, is the ‘Recalculate Taxes and Total’ button shown below the table? If so, click that, does it show line items then?

May 7, 2019 at 7:15 am

No, when the user requested a refund and his name was pulled up, that is what it showed.

Hmm, this is strange but it’s likely linked to whatever is causing the issue with line items.

I meant my original post and then this other registration. Both showing overpayment.

Ah, ok, so yeah they will show as overpayments due to there being no line items linked to the transactions, no lines items mean there’s nothing to apply to the payment to, so when a payment is applied it shows as an overpayment.

So in order to ‘fix’ the overpayment issue, we need to re-register the users manually and apply payments to them?

You need the line items to be generated and we don’t have and UI to do that (as its not expected that you would not have line items) so to fix, you’ll need to re-register them yes.

I think you mentioned, but I want to be clear, that if we do this, the next person on the waiting list will NOT trigger.

I was referring to a different situation there as you had 1 additional count on the sold value, meaning dropping a registration would NOT trigger the waitlist registrations in that case as the sold value would not be lower than the qty available.

If you cancel a registration and the Sold value drops below the ‘qty’ available, with auto promotion enabled it WILL promote a registration.

To prevent that you can first set the waitlist settings to have a number of ‘manually’ controlled spaces – https://monosnap.com/file/pzH6wDiXX8hm6GJ2J0r63lC1Yz4Erg

That way once you cancel the registrations, the spaces become available but they will be classed as manual spaces and the wait list add-on will not auto-promote them. You then add your ‘new’ (fixed) registrations and if you want EE to manage auto promotion after that, set the manual spaces back to 0 when finished.

If you want to be triple certain not to auto-promote registrations you could also temporarily disable the waitlist add-on before cancelling the registration, add them, cancel the originals and then re-enable it once again.

I have not updated the plugin due to the fact that there were a lot of registrations happening since it went live. I dont want to mess anything up. the client has events quarterly, so after this batch of events passes.

Sure, that’s up to you but also means you don’t get the latest bug fixes etc for your current event.

May 10, 2019 at 4:42 am

It most likely some form of caching, I can’t think of anything else that would cause it, from above:

There is no caching plugin installed on the website. It is hosted on a VPS server.

So no caching on the server side? You can have caching enabled on the VPS itself.

I’m assuming your managing the server yourself?

May 13, 2019 at 4:23 pm

Ok, so if your getting 503 errors, your server couldn’t handle the load at the time and you’ll end up with some rather unexpected results (such as having no line items) on registrations/transactions taking place at that time.