Events + Not recognizing Paypal payment status as paid

Okay, we launched the site the other day and the client has been doing some very rigorous testing. We came across an error right off the bat, where she signed up for a class on the site here:

http://werqfitness.com/registration/2013/01/instructor-training-woodstock-ga/

Completed the registration process, and signed up for the event through Paypal. Got a receipt from Paypal, but the payment is now showing as approved in the admin panel. It's still showing as "Not paid" in the RSVP export. I took a second look, and it would appear that ALL instances of people who have signed up are showing as unpaid.

This is a major problem, and I am hoping that it will receive the immediate attention that it requires.

If you need any info from me in the way of server logins, WP admin access, or anything else, please contact me directly.

One side note (and I know what you're going to say) -- some changes had to be made to the core to make it work for the client. I am running version 1.4.3, with a minimal amount of mods, none of which would have any impact on how the system ties in with Paypal. Just added a couple of fields for additional event data that was not available before. Just thought you would want to be aware of that. I will look forward to your reply.

  • aecnu

    Greetings lewismedia,

    Sorry to see that you are having these issues.

    PayPal IPN is it enabled and set with a return URL of some kind?

    Got a receipt from Paypal, but the payment is now showing as approved in the admin panel.

    Approved in the admin panel of PayPal or Events+?

    You are now 4 full versions behind and there were many many bug fixes. You really need to push an update because those missing updates include changes for WP 3.5

    Please advise.

    Cheers, Joe

    Please advise.

  • lewismedia

    I can upgrade, but it's going to take some time.

    PayPal IPN is it enabled and set with a return URL of some kind?

    No it is not setup. This does not appear anywhere in the Events + settings as far as I can tell. Please let me know where I need to enter this.

    Approved in the admin panel of PayPal or Events+?

    Paypal shows it. Events+ does not.

    I will work on upgrading, but in the meantime, please let me know about these two issues.

  • aecnu

    Greetings lewismedia,

    Thank you for your additional input and I can clearly see that you indeed have some concept issues on how this all fits together.

    First and foremost it is now certain that you do not have the PayPal IPN setup because of this statement:

    No it is not setup. This does not appear anywhere in the Events + settings as far as I can tell. Please let me know where I need to enter this.

    Because this has absolutely nothing to do with the Events+ plugin setting or Events+ itself and everything to do with PayPal.

    In your PayPal dashboard go to --> Profile --> My Selling Tools --> Instant payment notifications --> Update --> Turn the IPN on/enabled --> enter a URL to your site.

    Please advise.

    Cheers, Joe

  • lewismedia

    Hi, Joe! Thanks for getting back to me. You are absolutely right--I am definitely no Paypal expert.

    I'm going to throw a rod in the gears here and present you with some very interesting information.

    For starters, I upgraded the plugin to the latest version and tested it WITHOUT any of the custom mods. In Sandbox mode, it flunks the test (#@(! sandbox!). In live mode, it works... BUT... it only works with MY Paypal account. When I hook the client's Paypal account in place of mine, it doesn't work. I re-patched the plugin with my custom mods (a necessity, as there are some new fields for event type, and the location field is split up into Venue Name, Street Address, City, State, and ZIP, for more efficient and flexible queries on the events post type. It still works just fine with MY account, but when I hook it into the client's account, it stops working. Total brain-jar.

    Here's the fun stuff I promised you earlier: MY paypal account has nothing set for IPN. It has nothing set for the URL, and is turned off completely. Yet, it works. And the client's account does not (with, or without the IPN setting activated).

    It gets even more interesting...

    When I login to my Paypal account, it reads that I am setup with "Website Payments Pro" as a merchant solution.

    When I called Paypal to chew their ear for a bit (Mike Tyson style), the guy on the other end says I'm setup with Website Payments Standard, not pro. But my dashboard clearly indicates that I am signed up for Pro. The guy was kind of an a-hole, and very impatient. So, I ventured to try out a few more things on my own.

    The client has an exact copy of what I have in my account as a merchant solution. I tried adding the IPN stuff, activating Express Checkout, activating all of the API credentials (not sure why this would be necessary, as the Events+ plugin utilizes the "Buy Now" button ONLY, and specifies the return URL with a hidden field, dynamically generated by the plugin based on the permalink of the event landing page in question.

    So, regardless of what I enter in the IPN settings, when using Events+, it will always bring me back to the URL specified in the hidden field.

    At the end of the day, I am leaving you with this: the ball is in Paypal's court for the time being. I'm going to keep calling them until I get a useful, non-apathetic person on the other end of the line who is willing to help.

    In the meantime, if—based on the information I've provided here—you have anything else to offer, it would be greatly appreciated. Pretty much ready to climb a clock tower pretty soon if I can't figure this out. It's been more than two weeks since the problem appeared, and still nothing in the way of a solution.

    Cheers, and if I don't hear from you soon, a safe & happy New Year to you, Joe!

  • aecnu

    Greetings lewismedia and Happy New Year!

    Thank you for the details and a very intriguing things going on there.

    In Sandbox mode, it flunks the test (#@(! sandbox!)

    No surprise there, indeed I have mentioned a hundred times here in the forums that the PayPal sandbox is indeed erratic at best.

    Always test live and forgo the grief of the sandbox. I have actually seen people get things working in sandbox and then went live and they did not work! Good call by you on this one!

    It still works just fine with MY account, but when I hook it into the client's account, it stops working.

    Are you indeed using two browsers, one for development and the other for testing?

    This certainly does not make sense above unless with the clients account you are copying and pasting and there is a space being added to it that you cannot see, then it would make perfect sense.

    MY paypal account has nothing set for IPN. It has nothing set for the URL, and is turned off completely. Yet, it works. And the client's account does not (with, or without the IPN setting activated).

    The PayPal IPN is only relative to the return of the information to your installation after payment has been made.

    Are you perhaps indicating that Events+ is acknowledging the payment without having the IPN turned on? Or are you simply indicating that the payment is being accepted up to this point?

    activating all of the API credentials (not sure why this would be necessary, as the Events+ plugin utilizes the "Buy Now" button ONLY, and specifies the return URL with a hidden field, dynamically generated by the plugin based on the permalink of the event landing page in question

    The reason why the IPN must be enabled is because PayPal will not recognize the hidden URL that you mentioned is dynamically generated without this setting being turned on.

    It really does not matter what URL is in the return URL as long as there is one for the very reason given above - it is supplied by the script itself.

    So, regardless of what I enter in the IPN settings, when using Events+, it will always bring me back to the URL specified in the hidden field.

    IF the IPN is enabled.

    You mentioned about your own account working but not the clients but did not mention what kind of PayPal account the client has??

    Triple check for those empty spaces on the right of the credentials since this is the number one cause of this type of issue.

    Please advise.

    Cheers, Joe

  • lewismedia

    Fixed the problem. BUT, we now have a security hole in the site that will be a major issue if we leave it open. I removed the following code:

    if (!$booking_obj || !$booking_obj->id) {
        header('HTTP/1.0 404 Not Found');
        header('Content-type: text/plain; charset=UTF-8');
        print 'Booking not found';
        exit(0);
    }
    
    if ($booking_obj->event_id != $event_id) {
        header('HTTP/1.0 404 Not Found');
        header('Content-type: text/plain; charset=UTF-8');
        print 'Fake event id. REF: PP0';
        exit(0);
    }
    
    if (@$eab_options['currency'] != $currency) {
        header('HTTP/1.0 400 Bad Request');
        header('Content-type: text/plain; charset=UTF-8');
        print 'We were not expecting you. REF: PP1';
        exit(0);
    }
    
    //if ($amount != get_post_meta($event_id, 'incsub_event_fee', true)) {
    //if ($amount != $ticket_count * get_post_meta($event_id, 'incsub_event_fee', true)) {
    if ($amount != $ticket_count * apply_filters('eab-payment-event_price-for_user', get_post_meta($event_id, 'incsub_event_fee', true), $event_id, $booking_obj->user_id)) {
        header('HTTP/1.0 400 Bad Request');
        header('Content-type: text/plain; charset=UTF-8');
        print 'We were not expecting you. REF: PP2';
            exit(0);
    }
    
    if (!$ticket_count) {
        header('HTTP/1.0 400 Bad Request');
        header('Content-type: text/plain; charset=UTF-8');
        print 'Cheapskate. REF: PP2';
            exit(0);
    }
    
    if ($pay_to_email != @$eab_options['paypal_email']) {
        header('HTTP/1.0 400 Bad Request');
        header('Content-type: text/plain; charset=UTF-8');
        print 'We were not expecting you. REF: PP3';
        exit(0);
    }
    
    if (!$fp) {
        header('HTTP/1.0 400 Bad Request');
        header('Content-type: text/plain; charset=UTF-8');
        print 'We were not expecting you. REF: PP4';
        exit(0);

    Now it works. Funny thing is, when I used my own Paypal email in the settings, it worked even before, but when I used the client's Paypal email it did not. Now, it works either way.

    Any idea WHY this would be?? Needless to say, we need to get this code re-inserted after the issue is narrowed down and fixed.

    So, now that we've narrowed it down, where do we go from here to fix the problem?

  • aecnu

    Greetings lewismedia,

    Thank you for the additional input and for posting your code.

    We are definitely on to something though I do not know what and also another release has been made and it is version 1.5.2

    Please update and then see if we still have this issue with the PayPal accounts.

    Remember your snippet of coding above, we can remove it again if necessary.

    But meanwhile lets do the update and if it does not work but doing the snippet removal indeed makes it work let me know.

    In any event after the update and test, unless resolved without the snippet, I will ask the lead developer to come on here for help on this.\

    Have a GREAT weekend!

    Please advise.

    Cheers, Joe

  • lewismedia

    Hey Joe,

    Thanks for getting back to me, and for your comments. I updated the system to the latest version and without removing the error-checking code, it's still not recognizing the payments.

    To further that, my client just told me that even after removing the error-checking code above, they're still getting the "sometimes works, sometimes doesn't" from site visitors.

    Please have the lead developer on this project contact me directly as soon as possible. I can provide FTP access, WP admin access, whatever he needs. I am available any time during the week via phone, email, text, whatever you need. I will work with him on this until we resolve the issue.

    Thanks again, Joe. Hope you have an awesome weekend.

  • Vladislav

    Hello,

    Thank you very much for debugging the issue so well - since removing a part of the validation seemed to help, we can be fairly sure that PayPal IPN requests are reaching back to your server, which is good. However, there's possibly something bad happening above the codes you removed, and then the validation gets the wrong kind of data and drops the connection. Have you been able to determine exactly which of the checks you removed cause the payments to fail?

  • Vladislav

    Hello,

    Thanks for the swift response, and I totally understand your concerns. It would be really helpful if we could narrow the issue down to a particular check failing - this would be a good clue as to what exactly goes wrong, so we know which bit to scrutinize further. Since you mentioned different error codes on fails, a possible suspect would probably be $booking_obj variable - perhaps something goes wrong with instantiating or a corrupt piece of data somehow gets in. A close second would be $fp - perhaps communication back with PayPal to validate the request doesn't go as planned.

  • lewismedia

    Uploaded the beta, tried with and without custom mods. No dice.

    I only wonder... why would these two fields not be matching up? Now that we've got it nailed down to this small block of code, is there any other info I can provide that would help you debug? Nothing in the error log. I could trace the value of the variables throughout their short-lived existence and write them to a separate log file, if you think that might help?

  • aecnu

    Greetings lewismedia,

    Thank you for all of your time parsing through to get to the bottom of this issue though I am mystified why it is happening at all and not more wide spread i.e. you are the ONLY report of this type of issue that I am aware of.

    In any event, I will send a flag over to the lead developer just in case this ticket managed to get away from him in the back of the ticket system.

    Cheers, Joe

  • lewismedia

    Joe,

    I was finally able to take a look at this. Here's what I found out. The variables didn't match up:

    $pay_to_email ended up being equal to the admin_email option under wp_options in the DB.

    @$eab_options['paypal_email'] was equal to the paypal email setting under the Events+ payment options setting.

    So, at this point, I am only wondering--WHY is there an error checking mechanism in place that compares the Paypal email with the primary admin email? I mean, I get it... but there are just so many situations where the two would not be equal to each other.

    I am of the opinion that this error checking should be removed, or at least indicated somewhere in the settings that if the two emails are not equal to each other, this very error will be the result.

    Correct me if I'm wrong, but it would appear that we finally figured this out?

  • Vladislav

    Hi,

    Thank you so much for tracing the values - this is, indeed, an interesting find. The thing is, all these check actually validate various fields from the response from PayPal. The "$pay_to_email" is the "receiver_email" field (verbatim) - which is the primary email address for the PayPal account, and should be the same as the PayPal email from the plugin settings. The fact that it's not is quite interesting. Can you please verify that the primary email address in your client's PayPal settings and the email entered in the plugin settings actually match?

  • lewismedia

    Looks like both emails are on the account, but you are correct--the one entered in the plugin settings is NOT the primary email!

    As the non-primary email is the one I was given originally, I'm going to kill my client for putting me through this.

    Is there any way for you guys to update the plugin to match an array of values (i.e. all possible emails, not just the primary email) in the error checking, rather than just the one primary email? Seems like we wouldn't be losing any security by doing so?

  • Vladislav

    Hello,

    I'm really glad we finally managed to get to the bottom of this! It was a bumpy ride, and I can't thank you enough for all the patience, help and info you generously provided, not to mention the awesome debugging skills.

    As for the emails array matching, I agree, allowing this shouldn't cause a considerable loss in verification precision. However, my main concern about this is in the UI - adding one more email field for PayPal email in the settings could seem excessive and be a cause of confusion for less experienced users. Perhaps we could expose the email and/or email check (or the entire settings array, which is directly accessed here, without a wrapper - to ensure proper settings are loaded for child sites) for filtering via standard WordPress hooks?

  • aecnu

    Greetings lewismedia,

    It appears this particular topic is now resolved/closed, if you need any further assistance please let us know.

    If it wasn't resolved, or you have any more questions related to this thread, please feel free to post them below including any new symptoms or errors and tick the 'Mark as Not Resolved (re-open)' box below the post area (or else we'll miss it!)

    Thank you for being a WPMU Dev Community Member!

    Cheers, Joe