Posted: January 18, 2015 at 9:34 pm
|
Hi, It looks like both used had the same booking id. How can we resolve this? Cheers — |
Hi Nicolas, are you currently running or were you recently running any caching services (cloudflare) or caching plugins such as W3 total cache or WP super cache? — |
|
|
No. No caching plugins…. |
Alright, that is typically the cause but we can continue digging. Are you using the registration timeout option in the general settings page (event espresso –> general settings) of Event Espresso? Also, which payment methods are in use? — |
|
|
We are using securepay (AUS) as a payment gateway. The settings in general options are: Ticket Reservation Time (number of minutes registrants … Use registration limits on time slots? Yes |
|
Securepay? Is that the name found in the Payment Settings page? |
|
You guys developed this payment module for us about a year ago. And I believe it is now part of the available payment gateways. It is called Securepay (AustraliaPost) in the payment settings > Manage Payment Gateways |
|
When you say the users had the same booking id, do you mean the attendee id, or the registration id? |
|
The registration id is the same. |
|
Were they registered at the same time, using the “Add additional attendees” form? Or were they independent registrations? |
|
They were different registrations I believe. Note that the attendee_session is different and both registration are “is_primary” The time is the same because we had a lot of registration at that time for this event. “id”,”registration_id”,”is_primary”,”lname”,”fname”,”address”,”address2″,”city”,”state”,”zip”,”country_id”,”organization_name”,”vat_number”,”email”,”phone”,”date”,”price_option”,”orig_price”,”final_price”,”quantity”,”total_cost”,”amount_pd”,”coupon_code”,”payment”,”payment_status”,”txn_type”,”txn_id”,”payment_date”,”event_id”,”event_time”,”end_time”,”start_date”,”end_date”,”attendee_session”,”transaction_details”,”pre_approve”,”checked_in”,”checked_in_quantity”,”hashSalt” |
|
That is really odd. I can see that they are different session ids. I think I can see the issue now. The timestamps are exactly the same. Which means they both hit the function that generates the registration id at the same time, and the php function that we call, uniqid, returned the same “unique” id. I would guess that that function is seeded by the current timestamp. To prevent it from happening again, you could use the code here: https://gist.github.com/sidharrell/8da2c256c5ab6921ddf7 to generate longer, more random registration ids. |
The support post ‘Confirmation sent to wrong user’ 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.