Site turned to free despite payment going fine through stripe

The Stripe payment went through on Feb 19th for this site https://sto....com/bombfirst1 and Pro Site logs shows that subscription was set to "Starter" level as expected. The site, however, was reverted to "non pro site".

Site's renewed until Feb 16th were handled fine.

  • Panos

    Hi Ben ,

    Apologies for the delay!

    We're still trying to find what is the cause of this. We could not replicate on our test sites. I would like do some tests which would include the creation of test sites (one or two max) to check original payments, then we will force expire them and do simulated payments to see how site responds and if the blogs get updated or not.

    For this we would require ftp access. You can send ftp info privately through our contact form: https://premium.wpmudev.org/contact/#i-have-a-different-question

    Send in:Subject: "Attn: Panos Lyrakis"

    and include:

    - Admin login:
    Admin username
    Admin password
    Login url

    - FTP credentials
    host
    username
    password
    (and port if required)

    - link back to this thread for reference

    Thanks!

  • Ben

    To make sure we are testing the same thing:

    1. Are you testing against all the stripe api's. The stripe shop owner can choose what stripe api version they are using. If pro-sites is not instructing the user as to what stripe API they should be using, then you shouldn't expect the user to change the stripe api version to the latest. I've never received any instruction from wpmu dev on what version of api should be used...so...i'm guessing this is an oversight.

    2. Are you testing sub folder vs sub domain installs

    3. Are you testing against subscriptions created with previous versions? If changes were made in how data is handled vs each version, is pro-sites updating legacy subscriptions properly?

    4. Is they data you are expecting being tested? Many times when i was helping debug...different data was received than expected which was causing issues.

    Please let me know if you have tested all these things before proceeding. Hopefully this matter is urgent as most people wont know it is happening and as a result wont even be reporting it to you.

    -Ben

  • Panos

    Hi Ben ,

    I have been doing some testing and indeed there needs to be some change when the latest version of Stripe (2018-02-28 or ) is used. In my tests I got an error message from stripe:

    Stripe plan some_plan_name does not exist

    Although I don't see you mentioning this here, I am attaching a file to replace.

    However I think it would be better if you could share admin and ftp access to do some testing. Could you also check that payment you received in Stripe dashboard and click on it. Then scroll to the Events section (at the bottom of the page) and click on the most recent event. In the page that loads it should mention the json sent in the "Events Data" section, it should look similar to this:

    You can include that information along with the admin and ftp access message. I have mentioned how to send this information privately in a previous reply, please do not share this information on the forum :slight_smile:

    Thanks!

  • Panos

    Hi Ben ,

    This is strange. I believe it might be related to version 2016-03-07, I haven't tested with this version.

    I can test do some tests on your site with versions 2018-02-28 and version 2017-08-15. I would set my test api keys temporarily and create some test sites using both versions. Then I will restore your live keys.

    For this I would need admin and ftp access as mentioned. In case you send this info in please follow instruction from previous post above to use our contact form.

    If this works with latest version then I will suggest to update :slight_smile:

    Thanks!

  • Panos

    I tested the file I have attached above with more sites using latest Stripe API version. So I would recommend to:

    1. replace that file :
    wp-content/plugins/pro-sites/pro-sites-files/gateways/gateway-stripe.php
    It is attached in a previous reply

    2. Update your Stripe API version. It think it offers an option to update version for a few days and you can restore back. Instead of updating I could provide you with my test keys with latest api to try. Please let me know so I could provide them.

    3. Make a few tests and see if sites are getting activated.

    Please let us know how this goes.

    Thanks!

  • Ben

    Lets debug this together!

    You need the file:

    to get to line 1218, so that it can run:

    case 'invoice.payment_failed' :
          $psts->log_action( $blog_id, sprintf( __( 'Stripe webhook "%s" received: The %s payment has failed. Date: "%s", Charge ID "%s"', 'psts' ), $event_type, $amount_formatted, $date, $charge_id ) );
           $psts->email_notification( $blog_id, 'failed' );
           update_blog_option( $blog_id, 'psts_stripe_payment_failed', 1 );
           break;

    Because it is not getting there...which means no failed email notification is being sent out...and then the blog stays active...what F'ing mess.

    Please review your code in the file:

    Line 1065
    $event_type = $event_json->type;
    so be checking that to make sure you are getting the data you expect.

    Line 1114
    if ( $blog_id || $domain ) {

    What would happen if blog_id is not set? How long has blog_id been set the way it is currently set? Will older subscriptions started from versions before be set the same way...whats the history on this. Also of note...where is $domain ever set? Whats missing here.

    Line 1131
    case 'invoice.payment_failed'
    I think this might be getting hit now, because a user knew her card was stolen and when she logged in she new to put her new card in.

    So if thats the case (we are guessing) why is line 1218 not getting hit? Is there a error in that case statment getting triggered causing a blind catch exception?

    or is there something in here that would have a condition causing an error?

    // Should be Stripe regardless if its a trial, we need the proper information returned later
                                    $gateway = self::get_slug();
    
                                    // ... but we should record that it is a trial.
                                    if ( $is_trial ) {
                                            ProSites_Helper_Registration::set_trial( $blog_id, 1 );
                                    }
    
                                    $amount_formatted = $psts->format_currency( false, $amount );
                                    $charge_id        = ( isset( $event_json->data->object->charge ) ) ? $event_json->data->object->charge : $event_json->data->object->id;
    
                                    if ( ! empty( $plan ) ) {
                                            $plan_parts = explode( '_', $plan );
                                            $period     = array_pop( $plan_parts );
                                            $level      = array_pop( $plan_parts );
                                    }
                                    if ( ! empty( $blog_id ) ) {
                                            /*      reset the waiting status (this is used on the checkout screen to display a
                                                    notice to customers that actions are pending on their account) */
                                            update_blog_option( $blog_id, 'psts_stripe_waiting', 0 );
                                    }

    line 1253:

    catch
                    ( Exception $ex ) {
                            $message = $ex->getMessage();
                            die( $message );
                    }

    why are we not writing this to a log file...? Or even the network admin email! Anytime this fails...this a a major problem deserving extra attention.

    This issue is still a major bug and needs to be addressed.

    Panos please reach out so we can chat about this further and get this fixed for everybody once and for all.

  • Panos

    Hi Ben!

    I apologize as I wasn't working yesterday.

    Panos, any progress or further information on this, failed credit card billings are still not being recognized by pro-sites as being failed.

    Is this new a issue for failed payments? When there is a failed payment, it should not expire the site instantly. It will expire on next check for expired sites. Has the expiration date of that site passed already but it still has a pro level assigned?

    Also, could you please create a staging/testing site where we can replicate the issues you report?

    Thanks!

  • Adam Czajczyk

    Hello @benmiskie!

    Thank you for your response. It would be best if you could just provide Panos with direct access to the site so he could test what is needed to be tested in a way he thinks is necessary. If it's not possible then, I guess, any type of additional testing data might be handy but we don't have any "special mail" for that. Therefore I messaged Panos directly (as he's not working today) and he'll get back to you here once he's back online for work so you could establish some sort of non-public communication/data handling between you.

    He'll be get back to you here as soon as possible.

    Kind regards,
    Adam

  • Panos

    Hi Ben ,

    As Adam mentioned it would be more helpful to figure out what is going on if we had admin and ftp access. Best option would be to use a staging site where this issue can be replicated.

    In case you still don't feel like providing access I'm afraid there isn't anything we can do as we can't replicate. Perhaps we can try checking some custom logs. I have prepared a mu-plugin the would create 3 custom log files in the mu-plugins folder. You can download that file from here:
    https://gist.github.com/wpmudev-sls/8a7bfc7ca5b1c9a2c6af358be0a0d172

    and upload it to your wp-content/mu-plugins folder (if that folder doesn't exist you can create it).

    Once you have added that file, each time you receive a payment from stripe it should create/update 3 log files that could possibly point to what is going on. These files are
    ps-stripe.log
    ps-stripe-raw.log
    and
    ps-stripe-subscriptions.log

    So when this happens again we can check those logs to see what is different.

    Thanks!

  • Ben

    Add me on Facebook and I'll glad work through the logic. I am pretty confident there is no conflicts, you I can check you setup to make sure your config matches and I can help you walk through the logic with the log file to see where the logic fail is.
    >> Without access it is hard to tell

    This is what needs go be done, what else would you be needing with system access? Is there something I'm missing?

  • Panos

    Hi Ben!

    I am checking the logs but I would need to know if you have some specific blog_id that did a successful payment but it did not extend the pro level. Also date and time of payment if possible :slight_smile:

    what else would you be needing with system access?

    Since payment issues can be quite complex and do several checks in order to allow or disallow extension, we create test users with test subscriptions (test blogs) and send in test payment notifications (similar to what Stripe would send) to the payment gateway webhook. Each time we send we can follow the path via ftp and check where it fails. For example it retrieves no blog_id because the customer or subscription id are different. That was just an example.

    Add me on Facebook and I'll glad work through the logic.

    I'm sorry we don't work through Facebook

    I can check you setup to make sure your config matches

    We can't share access to our test sites. Also it might be related with changes made in time that have affected records in db not matching stripe info. We can't replicate this in a different system unless we copy db.

    Kind regards!

  • Ben

    I am checking the logs but I would need to know if you have some specific blog_id that did a successful payment but it did not extend the pro level. Also date and time of payment if possible

    Here's the frustrating part...I've given this information to you in the form of a screenshot that includes the pro-sites billing page showing the blog id, stripe subscription, stripe user id, shows that the prosites level is at 0, shows the date went through...all the good stuff needed to isolate the data to be reviewing in the logs and then manually simulating that posted data to see where the gap in logic exists in pro-sites....when I didn't see any action on this after a couple weeks...I re-followed up with the tech agent and delivered that information again.

    To my horror, if you are not getting this from the standard wpmu dev communication...then we need to figure something else out. I've been finding pro-sites update issues for a while now..and clearly no debugging on these issues I am finding are happening...so was suggesting a way around the road blocks...because i we could get this done fairly quickly in the debug method I am suggesting...I highly doubt this is a plugin conflict.

    So...if your tech support guys aren't giving you the necessary information I am repeatedly giving you, and given this is silently happening with no notification of the fails...making it a pretty dangerous bug...can you please suggest an alternative to me helping you and giving you the necessary information to debug. I clearly can't give you this information publicly.

  • Panos

    Hey Ben ,

    It was my fault! So sorry for missing it, I focused on the logs links that I didn't pay attention.

    Your screenshot is about blog_id 113 and payment made on June 4th

    Of what I see the payments for blog id 113 are failed from Stripe. You can confirm by checking the file ps-stripe-raw.log or for more clear results file ps-stripe.log. You will see that the event type is set to failed:

    event_type : invoice.payment_failed

    You can search using the browser search (ctrl+f) for 113. There will be several instances you will find, we focus to the invoice payment events. Eg on [ 04-06-2018 18:40:14 ] there is a failed payment for 113.

    Stripe continues though to try to repeat the payment a few times. There seems to be a successful payment on
    [ 06-06-2018 07:56:08 ] :
    "type": "invoice.payment_succeeded"

    So this should have activated the blog.

    What confuses me is that I see it has sent another failed payment notification on the next day
    07 Jun 2018 18:40:36

    If the blog is not active I assume that either the success payment didn't activate the blog on
    [ 06-06-2018 07:56:08 ]
    or that the blog was activated but the failed payment did expire it again on
    [07-06-2018 18:40:36]

    I tried to exclude either of the above in a test site of mine. But by expiring manually a site and re-sending a success request does reactivate it. Also when resending a "payment failed" request it doesn't expire the level.

    I'm afraid I can't think of anything else to suggest to try. Only way is to do similar request on your site and monitor what is happening on each request.

    Kind regards!

  • Ben

    Panos
    1) To clarify, i want to make sure and re-confirm you understand that i have opened other requests, and adam has requested that the conversation be limited to this one thread.

    For this most recent specific scenario, are you understanding that this scenario is that single user has TWO separate paid pro-site blogs created on different dates. Are you testing against this scenario or only a user with 1 blog

    2) You describe the scenario where a few fails occur, then a succeed, followed by a fail.

    So lets map that to a possible user action which would be VERY VERY common in subscription scenarios:
    1. Card is stolen or expired
    2. Next charge fails
    3. User logs into account after seeing fail email
    4. A shitty dialog appears....why shittty? Because instead of one simple primary step of allowing the user to maintain their subscription by simply adding updated card info to update their last ACTIVE subscription for the blog, they are forced to choose a new subscription for no reason further confusing them. Dumb dumb dumb. And more dumb :slight_smile:
    5. The user then enters in new card info, and a chooses a NEW subscription, to reactivate their site with
    6. Their site is re-activated. So now a NEW GOOD active subscription exists for blog ID X, and a secondary BAD subscription exists for blog ID X still floating around in the world not fully killed.
    7. Bad Stripe subscription, hearing no commands about what to do about its status, posts to blog X a message that the subscription for blog x is expired and changes the blog level to 0.

    Is this the correct set of events? Just want to make sure we are on the same page.

  • Ben

    Other notes, my user, as mentioned before has 2 blogs, blog 70, blog 113

    1) Reviewing the billing page on each site reveals that instead of there being one stripe customer id owning 2 subscription id's, there are instead different customer id's assigned to each blog with their own subscription id.

    2) through a support tech Nahid I have sent you screen shots of the 2 different customer ID information from stripe dashboard to show the various entries and times needed to help debug the logic/architecture of pro-sites. As you can see, possibly additional confusing data was sent to stripe when a logged in user tried to make a secondary blog in their account, so that process needs to be debugged as well for pro-sites logic errors (that i posted about possibly in another thread)

    I understand you didn't write this code, or the logic and you are just assigned to fixing it. There is a lot to fix, I hope you can get it done once and for all.

Thank NAME, for their help.

Let NAME know exactly why they deserved these points.

Gift a custom amount of points.