Posted: October 7, 2019 at 4:36 am
All our events have the default registration status “APPROVED”.
Is there a setting/shortcode/snippet etc. to disabled that behavior of EE4. No registration with RPP should be created. It should only either be a registration “APPROVED”/RAP after the payment has been fullfilled or no registration in the system at all.
By setting the Default Registration Status (DRS for short) to be ‘Approved’ you are telling EE to do the exact opposite of this. Setting a DRS of Approved basically says ‘I don’t care what the payment status is, every registration should be set to Approved’.
The default ‘Default Registration Status’ within EE is ‘Pending Payment’ and if you only want registrations that have paid to be Approved, that is the setting you should use on your events.
Sorry, I was not precise enough.
I do want the DRS to be “APPROVED”. That way, registrations are always approved although the related transaction is still not paid. That is as intended.
However, I do not want registrations with the status “NOT APPROVED” or “PENDING PAYMENT”.
The registration is created when someone comes to the payment processing step during the booking process. At that point, the registrations is created, but on a status “PENDING PAYMENT”. When the payment has been completed, the status of the registration will be set to the default registration status that is set in the event. In our case, the DRS is “APPROVED.
What I would like to have is that the registration is not created before the payment process, but after the payment process has been completed. That way, there will be no registration with status “PENDING PAYMENT”. How can that be achieved?
It can’t, at least not without completely rewriting the checkout process.
Event Espresso creates the registrations early on and then updates those in the database as each step progresses. To stop doing that would require EE’s checkout process to be completely re-written.
This is incorrect, Event Espresso creates the registrations early on and then updates those in the database as each step progresses. So registrations are created when ticket selections are submitted (select tickets on the ticket selector and submit) to stop doing that would require EE’s checkout process to be completely re-written.
You can check how this works by navigating to Event Espresso -> Registrations -> Incomplete.
Note the ID of the most current registration there.
Now add 2 tickets on an event (don’t enter details, just select 2 tickets and submit)
You’ll see those in the incomplete registrations list.
As you progress through the attendee information step, they’ll switch over to pending payment, refresh the page as you step through and look for the registration ID’s so you can see what I mean.
So, in order to have the behavior as I want, I would have to rewrite the whole registration process. Is that viable? Probably not and cannot be dunno through hooks anyway.
The other way would be to have a cronjob running every hour, cleaning up the registrations that are “PENDING PAYMENT”.
Any other idea?
If you don’t want registrations created until the end of the process, when payment has been completed then yes, that is correct.
I can’t really answer if it’s viable or not, that depends on how confident you are with PHP and building your own checkout process.
I can tell you that with the number of hooks available throughout EE it would likely be possible with the what we currently have, if not you are welcome to open a pull request to have some changes included in core to allow for it.
Personally, it’s not something I would undertake but ultimately that’s up to you.
That’s a possible option, but you’ll also need to take into account current registrations happening at the time when that cron is running, or you’ll delete registrations currently in progress.
I don’t have any ideas for this, our checkout process takes a lot of different factors into consideration, I can’t fire off ideas on how to work around how it works without it then having ripple effect throughout EE that would need to be taken into consideration.
However to run through some of the points raised above:
Just to clarify, the DRS is Applied when a registration is finalized, be that through an offline payment method (such as invoice) or when EE checks for abandoned offsite registrations, for example, when a user selects PayPal Express and is directed to PayPal then closes the browser. EE checks in the transaction when the user session expires (roughly an hour later) and closes the session, which in turn will apply the DRS setting.
For online payment methods where the user makes a payment in full, the DRS isn’t used as such. If a user pays the transaction total using an online payment method they are set to Approved, regardless of the DRS setting.
If you have a DRS of Not Approved, they wouldn’t have gotten to the payment options step without the admin changing their registration to at least pending payment, so the DRS does not apply in that situation when a payment is applied.
With a DRS of pending payment, a transaction is pending payment whilst it has monies owing, if the amount paid is equal to the transaction total, you’re no longer pending payment as… you have paid. Therefore the registration(s) is set to ‘Approved’.
Why not just filter them out? What issue are those registrations causing you?
As mentioned, this is incorrect, the registrations are created much earlier than that.
Correct, at the payment options step registration(s) will have been updated to have a status of ‘Pending Payment’, the DRS only applies when the registration is finalized (see above).
As explained above, this is incorrect.
The DRS technically has nothing to do with a payment, it’s the default status used when you finalize a registration. Payments applying to a transaction will trigger other status updates depending on that payment.
A partial payment (not officially supported but worth mentioning) may leave a transaction as pending payment, or it may trigger an update to be Approved. As it’s not officially supported its not something I can test on the front end, but it may well be that a partial payment currently does apply the DRS, even with a payment being applied.
Payment in full will always (by default) set the registrations to Approved. The transaction is complete, so the registrations apply to the event, which means they must be Approved.
If you had a DRS of Pending Payment and a user paid for the total transaction amount using an online payment method those registrations would be marks as Approved (which is the default setup for EE).
May I ask why?
If no registration is generated until payment, you can never follow up with abandoned registrations or identify issues with the checkout process… because you don’t have any data to follow.
Wow, thanks for the elaboration.
The support post ‘Do not create registration (RPP) if booking process was not completed fully’ is closed to new replies.
Have a question about this support post? Create a new support post in our support forums and include a link to this existing support post so we can help you.