Support

October 7, 2019 at 6:06 am

Hi Aragato,

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.

October 7, 2019 at 10:27 am

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.

The registration is created when someone comes to the payment processing step during the booking process.

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.

October 7, 2019 at 2:12 pm

So, in order to have the behavior as I want, I would have to rewrite the whole registration process.

If you don’t want registrations created until the end of the process, when payment has been completed then yes, that is correct.

Is that viable? Probably not and cannot be dunno through hooks anyway.

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.

The other way would be to have a cronjob running every hour, cleaning up the registrations that are “PENDING PAYMENT”.

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.

Any other idea?

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:

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.

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’.

However, I do not want registrations with the status “NOT APPROVED” or “PENDING PAYMENT”.

Why not just filter them out? What issue are those registrations causing you?

The registration is created when someone comes to the payment processing step during the booking process.

As mentioned, this is incorrect, the registrations are created much earlier than that.

At that point, the registrations is created, but on a status “PENDING PAYMENT”.

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).

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.

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).

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?

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.