Support

Home › Forums › Event Espresso Premium › Occasional error after payment

Occasional error after payment

Posted: August 22, 2022 at 5:33 am


stijl

August 22, 2022 at 5:33 am

Hello,

I’ve received two reports from users over the course of several months that they receive a “A valid Primary Registration for this Transaction could not be found” error after payment. I’m trying to find the problem but I haven’t been able to reproduce the problem.

Yesterday I received another report so I decided to investigate in-depth. I hope you can help me uncover what is going on!

I’m using the latest stable version of EE4 and WordPress. I’m not using any caching (as far as I know). And if that would be the case, I think the error would occur more frequently.
I’m using the Mollie payments add-on, that may be relevant.

All transactions for which I have received a user report of this error were completed successfully, with the confirmation e-mails sent. I have been unable to find anything unusual about either the registration or the transaction.

For yesterday’s case, here’s some data:

This is the TXN_session_data stored in the database:

a:13:{s:2:"id";s:32:"bd52ac9518cb1dbdb83421db5cbe58ee";s:7:"user_id";i:0;s:10:"ip_address";s:12:"[ip removed]";s:10:"user_agent";s:113:"Mozilla/5.0 (Linux; Android 11; FP3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/103.0.0.0 Mobile Safari/537.36";s:11:"init_access";i:1661109653;s:11:"last_access";i:1661109716;s:10:"expiration";i:1661113854;s:13:"pages_visited";a:7:{i:0;s:104:"[event url]/?ee=process_ticket_selections";i:1;s:104:"[event url]/?ee=process_ticket_selections";i:2;s:44:"[website url]/afronding-aanmelding/";i:3;s:46:"[website url]/wp-admin/admin-ajax.php";i:4;s:46:"[website url]/admin-ajax.php";i:5;s:46:"[website url]/wp-admin/admin-ajax.php";i:6;s:44:"[website url]/afronding-aanmelding/";}s:4:"cart";N;s:8:"checkout";N;s:11:"transaction";N;s:26:"selected_method_of_payment";s:12:"ideal_mollie";s:10:"ee_notices";a:3:{s:7:"success";a:1:{s:65:"EE_SPCO_Reg_Step_Payment_Options - _process_payment_status - 2445";s:34:"Uw betaling is succesvol verwerkt.";}s:6:"errors";b:0;s:9:"attention";b:0;}}

I’m unable to judge if this is normal or not. It seems normal compared to other TXN_session_data entries. (By the way, “afronding-aanmelding” is the Dutch slug for “Registration Checkout”, I think.)

From the server access logs, I find these relevant results:

[User IP removed] - - [21/Aug/2022:21:21:27 +0200] "POST /wp-admin/admin-ajax.php HTTP/1.1" 200 922 "[Website url]/afronding-aanmelding/?uts=1661109653" "Mozilla/5.0 (Linux; Android 11; FP3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/103.0.0.0 Mobile Safari/537.36"
87.233.217.244 - - [21/Aug/2022:21:21:52 +0200] "POST /transacties/?e_reg_url_link=1-4a0e3aef063f04920f6c3be85d815ccb&ee_payment_method=ideal_mollie HTTP/1.1" 200 774 "-" "Mollie HTTP client/1.0"
[User IP removed] - - [21/Aug/2022:21:21:55 +0200] "GET /afronding-aanmelding/?uts=1661109654&step=payment_options&action=process_gateway_response&selected_method_of_payment=ideal_mollie&spco_txn=545 HTTP/1.1" 302 679 "-" "Mozilla/5.0 (Linux; Android 11; FP3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/103.0.0.0 Mobile Safari/537.36"
[User IP removed] - - [21/Aug/2022:21:21:56 +0200] "GET /afronding-aanmelding/?uts=1661109654&step=payment_options&action=process_gateway_response&selected_method_of_payment=ideal_mollie&spco_txn=545 HTTP/1.1" 302 665 "https://www.mollie.com/" "Mozilla/5.0 (Linux; Android 11; FP3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/103.0.0.0 Mobile Safari/537.36"
[User IP removed] - - [21/Aug/2022:21:21:56 +0200] "GET /afronding-aanmelding/?uts=1661109654&step=finalize_registration HTTP/1.1" 200 28308 "-" "Mozilla/5.0 (Linux; Android 11; FP3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/103.0.0.0 Mobile Safari/537.36"

You can see that the transaction has been completed quickly, so there are no timeout problems. The user agent and IP are the same, so the session should be fine. However, you can see the two 320 HTTP status code responses, probably corresponding to the error reported by the user.

I really don’t know what is going on here and why Event Espresso throws the error. The php error log is empty. Can you help me find out what causes the error? My customers find it confusing and stressful, so I hope to resolve it!

Let me know if you need more (database) information and I can supply it privately! I would prefer not to give you access to the server due to privacy regulations.

Thanks!


stijl

August 22, 2022 at 5:37 am

Correction, I meant 302 HTTP status codes. But that’s just a redirect so no useful information there either.


Joao Victor

  • Support Staff

    •

August 24, 2022 at 2:28 pm

Hi there,

Thanks for contacting us. I am Joao from the Event Espresso support!

Do you know if these customers spent more time than usual during the checkout? Event Espresso has a limit of 1 hour by default to complete the registration process. Based on your event, do you think you need to add more time to your users? You can add the following custom snippet to see if it prevent the problem:

add_filter( 
'FHEE__EE_Session__construct___lifespan', 
'ee_change_reg_time_limit' 
);
function ee_change_reg_time_limit() {
 return 2 * HOUR_IN_SECONDS;
}


stijl

August 25, 2022 at 3:32 am

Hi Joao,

From the HTTP access logs (included in my first post) you can see that the customer did not spend a lot of time in the checkout, so I’m confident there’s no timeout issue.


Tony

  • Support Staff

    •

August 26, 2022 at 5:56 am

Hmm, ok. I don’t think this is a timeout issue either.

The log entries above don’t really help narrow this down at all.

However, this specific error:

“A valid Primary Registration for this Transaction could not be found”

Is only thrown in one location within EE (which helps a little here) and that’s on the Finalize Registration step.

The reason that helps ‘some’ is we know a little more about where the error is from and based on how the Mollie payment method works it helps to know that.

So what I can tell from the error itself, is the finalize registration step initialized using the checkout object but then when a check was run to confirm the primary registrant had been set, there wasn’t one, why? I can’t say from what we have above.

However, there is a hook within the function calling the above:

do_action(
    'AHEE__EE_SPCO_Reg_Step_Finalize_Registration__process_reg_step__completed',
    $this->checkout,
    $txn_update_params
);

This means we can hook into it there and log what the checkout is doing and what txn_update_params had been passed in to see if that helps…. problem is it isn’t something we can reproduce so it’s a case of setting up the log and then waiting for it happen again.

The way I would do it is by using a function like this:

//Debug function to easily write various vars to the log.
if ( ! function_exists('tw_ee_write_log')) {
   function tw_ee_write_log( $log )  {
      if ( is_array( $log ) || is_object( $log ) ) {
         error_log( print_r( $log, true ) );
      } else {
         error_log( $log );
      }
   }
}

Which adds whatever you pass it to the error logs.

The problem with using that is you may need to enable WP_DEBUG_LOG for it to work, for that you can use a snippet like this:

https://eventespresso.com/wiki/troubleshooting-checklist/#wpdebug

That snippet replaces the define( 'WP_DEBUG', false ); in your wp-config.php file and writes the logs to /wp-content/debug.log

Then something like:

add_action(
    'AHEE__EE_SPCO_Reg_Step_Finalize_Registration__process_reg_step__completed',
    'tw_ee_log_process_reg_step__completed',
    10,
    2
);
function tw_ee_log_process_reg_step__completed($checkout, $txn_update_params) {
    if (! $checkout->transaction_has_primary_registrant()) {
        tw_ee_write_log(
            array(
                'Checkout' => $checkout,
                'txn_update_params' => $txn_update_params
            )
        );
    }
}

All in one gist:

https://gist.github.com/Pebblo/f0e23788de4586da5a217229b1a83839

You can add that to a custom functions plugin on your site, we have some documentation on creating one here:

https://eventespresso.com/wiki/create-site-specific-plugin-wordpress-site/

Because that hook is fired for every update, I use the same check the error message uses before its display, so if a primary registrant isn’t set, we get the checkout and update params logged to see what data is actually being used on that request.

Once we have that… we may be able to narrow this down some.

What I suspect is happening right now is something is clearing out the WP transients on a schedule but I’m only saying that as it’s the only thing I can think of with the info we have. So we need the above to see if helps at all.


stijl

August 29, 2022 at 3:59 am

Perfect, thank you! I will get back to you when I have the results.


stijl

September 7, 2022 at 10:20 am

I’ve got results, but some log entries are 20+ MB (because the EE_Checkout object links to many other objects). How can I conveniently transfer them to you?

From my first glance, it seems that the session transients are present. And I got some additional user reports of other errors at the same stage in checkout (with different or no error messages, and thus without additional debug info). I’m not sure if those are related, but it could indicate a wider problem. The main common factor I have found is that the error messages only occur after the Mollie payment was (successfully) completed.


Tony

  • Support Staff

    •

September 7, 2022 at 3:00 pm

Place everything in a single directory and zip that directory and use something like WeTransfer to send it over to support[at]eventespresso.com and I’ll take a look.


stijl

September 13, 2022 at 5:44 am

This reply has been marked as private.

The support post ‘Occasional error after payment’ 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.

Support forum for Event Espresso 3 and Event Espresso 4.
Documentation for EE3 and EE4
Documentation for Event Espresso 3 Documentation for Event Espresso 4

Status: closed

Updated by  stijl 1 year, 7 months ago ago

Topic Tags

Notifications

This topic is: not resolved
Event Espresso