Posted: December 23, 2013 at 12:07 pm
|
New Thread… as requested. —- PREVIOUS THREAD —– I’ve been all through the forums looking for something very similar to this issue. — Hi TheWHEGroup, — I’m getting those server logs now. — NO caching enabled, plugin or server side —
|
I don’t believe so, I’ve tried testing this a few different ways and the IPN will always eventually update the status to Complete after paying even if there was a free event in the cart. This is testing Event Espresso 3.1.36.1 though, so your results may vary with 3.1.35. |
|
|
To be clear, when a registrant checks out on our system (and this all worked fine in Sandbox and does work intermittently for some users) if they have free and paid events in their cart, the free events are marked Complete and the paid events don’t get updated. The transaction (IPN) info is not populated. But, PayPal reports that it got a 200. There are no errors in any EE logs. BUT, there is also NO entry in the IPN log. Something is most certainly up here and it’s getting very frustrating. “My results may vary” is not an acceptable response for a minor incremental upgrade. There is NO indication any code whatsoever changed in the payment code, unless you failed to note it. Please advise how we can begin to escalate this issue. |
|
New TEST Scenario for you to run! This might be it! I have tried this a couple times and it fails/succeeds consistently so far. This seems to be Event ID dependent. If the event with the LOWEST Event ID in the Registration is a FREE event it fails. If the event with the LOWEST Event ID in the Registration is a PAID event it succeeds. Look at your logic for how you create the RegistrationID. You use the lowest Event Id (e.g. 3-52bf6f9a2c0ee) from the particular cart checkout. That was my clue. I saw bunch of registrations with a low Event ID prefix failing. Those with higher EventID prefixes were not failing – we had entered all our free events first, thus they have a lower ID. So I began digging deeper into our records and this seems to be a good bug candidate. Please check and advise ASAP. I can edit code for a hot fix if you have some. — Peter |
|
Hey Peter, thanks for your patience. We’ve tested and reproduced the problem and found the fix for it. In gateways/process_payments.php on line 47 is the function espresso_get_total_cost. You can either make the changes to that function, or override it using the code here. If you override it, you can add this code to one of the following: $sql = "SELECT a.final_price, a.quantity, a.amount_pd FROM " . EVENTS_ATTENDEE_TABLE . " a "; then after line 60: $total_quantity = 0; place this line: $amount_pd = 0; then after line 66: $total_quantity += $ticket['quantity']; place this line: $amount_pd += $ticket['amount_pd']; and after line 81: $payment_data['quantity'] = $total_quantity; place these lines: $payment_data['amount_pd'] = number_format( $amount_pd, 2, '.', '' ); $payment_data['amount_owed'] = number_format( $total_cost-$amount_pd, 2, '.', ''); Finally, whether you override that function or change it directly, go down and find (approximately line 199): if ( $payment_data['payment_status'] != 'Completed' && $payment_data['payment_status'] != 'Refund' ) { and change it to: if ( $payment_data['amount_owed'] > 0.00 && $payment_data['payment_status'] != 'Refund' ) { Note that line numbers are approximate, since I’m looking in EE 3.1.37-Alpha, so I’ve included the old code or the line above where you need to insert code to help you locate where to make the changes. if ( $payment_data['payment_status'] != 'Completed' && $payment_data['payment_status'] != 'Refund' ) { and make the same change to it: if ( $payment_data['amount_owed'] > 0.00 && $payment_data['payment_status'] != 'Refund' ) { |
|
YES! That sure seems to have fixed it. We’ll keep an eye out and let you know if there’s any additional issues, but it seems to have worked for the scenario we discovered. We changed the code directly. Thanks for the excellent response and for not making us wait for an official update! — Peter |
|
Thanks. What we found was that it was adding the free event to the cart first that set it off. Since that determined the order of the events on the page where you enter the attendee information, and the first attendee on that page is marked as the primary attendee. It’s the primary attendee’s payment status that was being checked when the IPN message came back from paypal. |
Sidney’s fixes were added to the Event Espresso 3.1.36.2.P release, so anyone else seeing this issue should update if they haven not already done so. |
|
The support post ‘Paypal IPN not being received by Event espresso (new thread)’ 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.