Support

August 2, 2022 at 1:38 pm

Hi there,

I am seeing Registration Approved messaging being triggered on the Paypal Express gateway even if the Paypal transaction is canceled. This does not seem correct. In my view, if the Paypal offsite flow is canceled by the customer, it should be as if nothing happened with the Registration.

This depends on how your event is set up, more specifically what your ‘Default Registration Status’ (DRS for short) is set to.

When reading over your thread and getting to this:

I have been doing extensive testing and I even discovered that if the event is set to default “Pending Payment” status after registration, the customer receives a Pending Payment email.

It gave me the impression that you have the Default Registration Status set to Approved and looking over your site I can see that is the case.

It’s that setting which is telling Event Espresso to approve all registrations regardless of payment status because that is exactly what that setting is intended to do.

The DRS option is there to allow you to set what happens to registrations by default when they finalize, a default registration status of ‘Approved’ tells Event Espresso (in English) “I don’t care about what happens with the payment, approve the registration so they take a space” which then allows the admin to work from there if needed.

The majority of users want a DRS of ‘Pending Payment’ (which is the default value EE uses when installed), a registration that is pending payment automatically switches to approved when the amount owing is 0 (however it ends up getting there), because that registration is no longer pending payment if there is no payment amount remaining.

I do not want any email sent until the Paypal offsite is completed with full payment at Paypal. If someone cancels at Paypal and returns to the site, there should be no messaging at all.

We don’t have an option for this currently, pending payment emails sent when someone cancels a payment or makes it to the thank you page without paying is the minimum we have available.

You ‘could’ set the DRS to Pending Payment and then disable the pending payment email template so it doesn’t trigger a message. When the registration switches to Approved if a payment is made, that would still trigger the Registration Approved email with that setup. However, one of the reasons for the pending payment email is to give a way for users to complete payment on registrations at a later date if they need to, you’ll lose that and any other acknowledgement from the site for ‘pending payment’ registrations with that set up.

How can I achieve this? Is there a filter or hook that can be set to intercept the return value of the Paypal offsite interaction?

Just to clarify, the step here isn’t an issue with PayPal/the payment method itself.

Our Single Page CheckOut process (SPCO for short) handles the interaction for the registration step, payments options step and finalization step. The payment method (in this case PayPal Express) sits in the Payment options step and handles the payment object passed within the EE_Transaction, it then updates the transaction based on what the payment does and SPCO progresses to the finalization step, which basically checks over the transaction and updates the registrations as needed, triggering messages as it does. So the payment method does its thing and then SPCO works after that which then triggers messages.

Please let me know how to address this problem with the EE Paypal Express Plugin – which I believe is an EE-officially-supported Plugin.

PayPal Express is one of our core payment methods, it’s included within EE4 core so yes it is an officially supported payment method, however, with your current event set up EE4 (and PayPal Express) appear to be working as intended.

August 2, 2022 at 4:03 pm

We have been exclusively using the Paypal Pro gateway. It makes me think that I have had the wrong mental model of that system because we do Approve all registrations, but that has not been an issue because when the Paypal Pro flow fails (because of rejected credit card or any other rejection from Paypal) the system sends a Payment Failed email and – critically – does not send a Registration Approved email.

Hmmm yeah, so it does work slightly differently here depending on the Payment Method and whilst that sounds like it contradicts what I just said I’ll explain because its still SPCO that does the processing, its just where the payment method is sending the data changes what happens some.

If a payment method handles payment failing within itself and allows you to reattempt payment, or literally does nothing but show the payment fields again then it can trigger the payment-related emails each time but not progress onto the finalization step to trigger registration based emails.

Now… this gets tricky to say ‘This is going to happen every time’ because some payment methods integrate with others in the background (Like PayPay PayFlow does on their end) and some payment methods force us to return back to the site on failure, some don’t.

So the short answer is if a payment method handles failures within the form itself without forcing you back to the site, you’ll get payment-related emails but not registration based. If a payment method forces you back on failure, it will usually go to the thank you page (which runs finalization) so you’ll get both payment and registration emails. Some payment method allows us to pass 2 URLs, one for a return URL (which we pass a URL that will redirect back to payment options) or a redirect URL (which sends the ‘processing’ URL) which will redirect back to the transaction processing than the thank you page, again it’s up to the payment method integration.

This is exactly how I would have thought the Paypal Express flow would work too! If there is a “failure” at the payment side, the system should say “payment failed” – not payment pending, and certainly not Registration Approved.

PayPal express takes the redirect URL, so force you back to the thank you page, which yes, will trigger the registration emails. But ‘registration approved’ is incorrect, that’s based on your settings, not the payment method.

I have to ask this question – why isn’t Registration Approval tied to the Payment Success?

Because not every payment means the transaction is complete 😉

And not every transaction needs to be complete for an admin to want the registration to apply to sold values straight away.

Basically, the system is designed to give as much flexibility as possible and to do that we decouple everything but tie in certain criteria to do other actions.

For example, an incomplete transaction updates to complete when all moneis owed are paid. A transaction updating to complete, updates the registrations assigned to it to be Approved, because thats the ‘natural’ progression of a transaction/registration etc. But the admin can also override a lot of that when applying payments.

I mean, in many, many use cases (including ours) you would not want to Approve Registration when the Payment was not completed.

That’s exactly how EE is set up by default, use a DRS of Pending Payment and that’s what it does.

And, in fact, this is how the system seems to behave when using the Paypal Pro flow – but not the Paypal Express flow.

That’s based around the above, payment method and the DRS set on the event.

The majority of users want to use a DRS of Pending Payment, its how most people expect a ‘payment’ system to work. A registration sits at Pending Payment until payment is made in full in which is switches to Approved and counts towards the sold values.

In any case, I think we may be able to use your suggested solution and suppress the Pending Payment emails for these events that use the Paypal Express flow.

You know how to create a ‘disabled’ Pending Payment custom template so it can be set on the events?

The only issue with this solution is that all of the Registration Approved statuses for these events will have to be manually set to move the purchase forward. Unless you have further advice to enable automatic Registration on Payment Success status!

Sorry, I’m not sure I follow, can you add some more details.

I should be able to set a switch on an event (no matter which Payment Method is used) labeled something like this: “Full Registration is only approved after payment is completed.”

That setting seems to be missing as a general setting for the current EE event Registration-Payment architecture. Or am I missing something?

Oh, if that’s linked to the above… that’s your Default Registration Status.

Set it to pending payment and test a registration, you’ll see it switches to Approved on full payment and stays at Pending Payment otherwise.

Is that not what you are looking for?

August 3, 2022 at 4:30 pm

set up a “deadletter” email message custom message type for “Registration Pending Payment” for Primary Registrant message

Set the TO field to nothing, as in empty, for that custom message type and it ‘disables’ sending an email completely.

Or click the toggle switch to disable it.

You don’t need to ‘send’ the email to a dead address 🙂 just get EE to now send it at all using a custom message template.

However, I have one final test and that is that we are offering this new Express payment method alongside the “Paypal Pro” flow. We have never used the Pending Payment as the DRS so I am hoping that it “Just Works.”

It should 🙂

From what you’ve mentioned it should just work how you are expecting, especially now you have a ‘dead’ pending payment message type on the event.

Only the registration Approved email should send when payment is made in full now with the step you are using.

I have to say it was very confusing to get all of those moving parts in order and with the correct combinations of suppressed emails and registration settings. But, in the end I think it will work.

The problem with messages is everyone wants different things from it so we had to make it flexible enough to handle a lot of situations, with that comes some complexity when changing things up.

Kind regards and kudos to your excellent support!

Thank you and I’m more than happy to help.