|
Philip Wall
|
April 5, 2017 at 4:42 am
We are having an issue whereby payments are showing incomplete in EE but showing complete in Mijireh (I have emailed them now). We had one customer paying five times as a result. “Every time I put in the payment it told me web page could not displayed.” I am unable to replicate this issue myself. We use caching plugins WP Super Cache and Autoptimize and I have added the checkout/EE pages as exceptions in WP Super cache. Today I updated to the latest version of Avada. Registrations that were showing incomplete yesterday now have a complete AND incomplete confirmation in Registrations section.
|
|
Josh
|
April 5, 2017 at 6:35 am
Hi Philip,
Can you go to the Event Espresso > Transactions page, then click on to view the Incomplete Transactions there? Once you do that, does the Transaction automatically update?
|
|
Philip Wall
|
April 5, 2017 at 6:53 am
Hi Josh,
I tried that for one transaction and it changed from incomplete to complete. It did not work for some that had ‘failed’ (on these there was a message in Mijireh saying ‘ERROR INFO:
This transaction (xxxxxx) has already been processed! If you feel this is incorrect please contact the merchant!’)
Usually this inbuilt error prevents people making duplicate payments on the same course (I think) and yet for one customer whose email I can send you privately, was able to pay 5 times. We are also getting reports from a lot of customers saying they are not receiving their confirmation emails.
|
|
Josh
|
April 5, 2017 at 7:09 am
You can check the Messages Activity list table to see what the errors are for the emails that didn’t get received.
It will also help to add some text to the Slurp page that says to make the payment one time. Mijireh will allow them to keep paying if they keep trying. After you add the text, you can reslurp the page and your message will appear on the billing info page.
|
|
Philip Wall
|
April 5, 2017 at 7:16 am
Hi Josh,
I will try that, in the meantime is there any way you guys can check if the caching plugins are causing this problem? Autoptimize and wp super cache. I have added exceptions to WP Super Cache.
We really need to find out why so many payments are going to pending/incomplete *(and yet today some that were pending showed up twice as pending AND complete). There’s something wrong in the system.
Mijireh responded with the following;
Apr 5, 7:48 AM EDT
Hello Philip,
When Mijireh receives a successful payment indication from your payment gateway, we will redirect the customer back to your site – some kind of a “thank you” or “payment received” page, and it is the job of this page to mark the payment as paid in the back-end of your system. Usually when a problem like this occurs, there is some problem with that page or the website itself that is causing that page to not complete this task. This page is part of the Event Espresso system, and something that runs on your website. I would suggest you contact Event Espresso support about this matter. Please keep us updated on the progress so that we can be ready to help if needed.
|
|
Philip Wall
|
April 5, 2017 at 7:20 am
I’ve found the email culprit, some people are putting in @gmail.con and hotmail.con rather than .com. Wonder if there’s a better way to validate emails.
|
|
Josh
|
April 5, 2017 at 7:33 am
Hi Philip,
We do not support caching plugins. One thing to keep in mind is Mijireh doesn’t actually handle the payment processing, they’re in between the Payment Processor and your site that uses Event Espresso. If there’s a delay between the 3rd party payment processor and Mijireh then the transaction data will not be ready for when the user returns to the Thank You page. It’s important to be aware of this and add messaging to your site that informs the user of this potential delay.
Wonder if there’s a better way to validate emails.
You can set different levels of Email Validation by going to Event Espresso > Registration Forms > Reg Form Settings. The options there include:
Basic
WordPress Default
International
International + DNS Check
The last option listed above adds a DNS check which will prevent an email address with @gmail.con from being submitted.
|
