|
Ray
|
November 7, 2014 at 8:59 am
Hi – for EE4, is it possible for the Registration emails to be sent AFTER payment information? I’ve seen several posts about this topic but this option does not exist in EE4–> General Settings.
Thanks.
|
|
Tony
|
November 7, 2014 at 9:53 am
Hi Ray,
The previous posts you have seen would likely all relate to EE3.
Within EE4 the messages (emails) are handled differently and the Registration status is independent of the Transaction status. This offers much more flexibility on what can be achieved over EE3.
However, by default when you register onto an event, the Registration is given a status of ‘Pending Payment’ and a ‘Registration Pending Payment’ message is sent. The transaction for that registration is send to
This is to confirm the registration is received but that it is still pending payment.
Then, the user pays online via one of the online gateways (lets say Paypal) EE updates the status to Approved and the transaction is set to complete.
Now a ‘Registration Approved’ message is sent, this email should contain any information that you want to send as a ‘Confirmation email’ for when a user is fully paid.
So by default, ‘Confirmation emails’ are NOT sent before payment is received although you can alter this by altering the default registration status. The messages system within EE4 is very powerful and can accommodate most users needs even if it is not setup to do so by default.
|
|
Ray
|
November 7, 2014 at 10:56 am
Hi Tony – thanks for your detailed message. I understand the flexibility is better but can you help me understand how this actually is better than EE3 when you have multiple payment options? Otherwise, if you change the default registration status, then you have to manually changes statuses for invoice and check payments.
For example, if a user pays by invoice or check, then you get an email “pending payment” and then another email later stating “payment received”, which is great.
However, if the user pays by credit card, then they get two emails, which isn’t user friendly. We can’t change this to just one email, correct?
In the end, you’re basically stuck in the same situation as EE3, where the email system is best for one type of payment system. No?
|
|
Sidney Harrell
|
November 7, 2014 at 12:50 pm
They shouldn’t be getting a “Pending payment” email if they use a credit card gateway like Paypal. They should only get the successful payment email and the registration details email.
|
|
Josh
|
November 7, 2014 at 12:55 pm
Hi Ray,
It turns in Event Espresso 4 you can change it to send just one email for when they pay by credit card. You can do this by disabling the Registration Approved message.
When you disable the Registration Approved message, people who pay by credit card will only get the Payment Details message. That’s one email.
People who pay by invoice will continue to get the Registration Pending Payment email, and later the Payment Received email. That’s two emails, one before they pay, and one after they Pay.
You can disable a specific message context by blanking out the To: field for any email context, then saving.
|
|
Ray
|
November 10, 2014 at 10:08 am
Hi Josh – one problem w/ that method is that if multiple people register at the same time. The Payment Details message only goes to the Primary Registrant. The Registration Approved message goes to both Primary and other Registrants. Unless we can change who get’s what message w/o back-end coding.
Thanks.
|
|
Lorenzo Orlando Caum
|
November 11, 2014 at 2:29 pm
Hi,
The primary registrant receives the notification for payment received as that individual is the one that has completed the payment.
Could you rephrase your question? We’ll then you you know if that is available without custom coding.
—
Lorenzo
|
|
Ray
|
November 12, 2014 at 8:03 am
Ok – below are three scenarios that I hope clarifies up. Basically, there are too many emails being sent and turning-off the “Registration Approved” email doesn’t work if someone purchases multiple tickets. Please take a look. Thanks.
Scenario 1:
Number of tickets purchased: 1 by Primary Registrant
Payment Method: Credit Card
Mail Server: Mandrill
Emails Received: 3
1 email from Registration Approved Primary Registrant Template to [PRIMARY_REGISTRANT_EMAIL]
1 email from Registration Approved Registrant Template to [RECIPIENT_EMAIL]
1 email from Payment Received Primary Registrant Template to [PRIMARY_REGISTRANT_EMAIL]
Desired Scenario: Primary Registrant receives ONE email.
Scenario 2:
Number of tickets purchased: 2 by Primary Registrant and Secondary Registrant
Payment Method: Credit Card
Mail Server: Mandrill
Emails Received: 3 by Primary Registrant and 1 by Secondary Registrant
Primary Registrant receives the following emails:
1 email from Registration Approved Primary Registrant Template to [PRIMARY_REGISTRANT_EMAIL]
1 email from Registration Approved Registrant Template to [RECIPIENT_EMAIL]
1 email from Payment Received Primary Registrant Template to [PRIMARY_REGISTRANT_EMAIL]
Secondary Registrant receives the following email:
1 email from Registration Approved Registrant Template to [RECIPIENT_EMAIL]
Desired Outcome: send ONE email to Primary Registrant; Secondary Registrant is ok
Scenario 3:
Number of tickets purchased: 2 by Primary Registrant and Secondary Registrant
Payment Method: Invoice
Mail Server: Mandrill
Emails Received before payment: 1 to Primary Registrant and 0 to Secondary Registrant
Emails Received after payment: 2 to Primary Registrant and 1 to Secondary Registrant.
– in this case, the Secondary Registrant doesn’t get any email confirmation until the payment has been made.
Desired Outcome: Send Secondary Registrant a similar email about his/her registration.
|
|
Josh
|
November 12, 2014 at 2:08 pm
Hi Ray,
Here’s one thing you can do that will reduce the number of emails that go to the primary registrant that does not involve custom coding:
You can disable the Registration Approved Primary Registrant email for the primary attendee by blanking out the To: field in the Primary Registrant context, then saving.
I’ll be sure to pass along the rest of your feedback to the dev team.
|
