Billing Upgrade bugs

Recently a customer's credit card needed to be updated. Their billing expired, and then the received and email asking them to update.

They logged in, choose a different billing plan "custom for 360/yr" to replace their older higher tier plan (prev customer 264/yr) then added a $96 coupon code to make their plan 264 yr.

They completed their transaction and then their site billing was in order.

However reviewing the billing page for this client shows things are not reflecting the users transaction.

In addition, there is no "cancel" button being rendered. Reviewing the code, it appears that the following variable:

$psts->is_blog_canceled( $blog_id ) in the file pro-sites-files/gateways/gateway-stripe.php is rendering the number 1. Because it is returning 1, the cancel link will not appear.

So wondering if the developer could review what is going on here as things dont appear to be functioning as expected.

Thanks

  • Ben

    Upon further review...maybe I'm reading your code wrong....don't think I am

    the function is_blog_canceled in file: pro-sites.php
    performs the following:
    update_blog_option( $blog_id, 'psts_is_canceled', 1 );
    and subsequently when this variable is set, if it is found it will automatically set the function to return true. There is no place that I can see in your code where this variable will get unset or set to 0.

    So given that the cancel button relies on the is_blog_canceled function not returning true...and given that when the blog variable psts_is_canceled is set once to true then is_blog_canceled will always return true, and that there is no place in the code base to unset it from being true...the cancel button will forever be removed and clients will wonder what is going on.

    Is this a bug or am I reading it wrong?

    -Ben

  • Ben

    I am just spot checking another site...and it is really disappointing the result on another billing situation...

    The site is on an annual plan, and on the renewel, stripe attempted to bill the card 4 times, and it failed 4 times. However instead of the site being cancelled or its pro-site level being removed...the level stayed on and suggests to the user that billing went through.

    However reviewing the stripe, it didn't go through. So...another thing to add to the billing issues of pro-sites...what is happening over there guys. I have no idea how many sites are like this...but this really deserves some immediate attention.

    Here's a screen shot showing the folly. The billing logic and fail scenarios seem to not be thought through.

  • Patrick

    Hiya Ben Happy New Year! :smiley:

    However reviewing the billing page for this client shows things are not reflecting the users transaction.

    The screenshot in your 1st post above looks correct. The payment amount is not showing in the summary box at the top as it is considered a 1st payment after a plan & payment method change. However, the expiry date in that box, as well as the amount & payment date/method do appear to be correctly reflected in the details box below.

    As for the function you were looking at, you may have overlooked the conditional check it is wrapped in, as well as the other 2 conditionals in that same function in pro-sites.php. You need to look at the whole is_blog_canceled function. update_blog_option will only return true for psts_is_canceled if pro site status or Stripe payment has already been canceled.

    As for the 2nd screenshot, that also looks correct to me. Although the latest payment failed and the user was notified, the current pro site status will continue until the current expiry date, which in that case, would be one year after last payment: Feb 4, 2018

    Please do let me know if I've misunderstood any of these issues, or if this helps clarify things a bit. :slight_smile:

  • Ben

    Patrick, thanks for reviewing. We need Umesh to look at this asap.

    >> The screenshot in your 1st post above looks correct.
    No. There is nothing correct about this page.

    >> The payment amount is not showing in the summary
    >> box at the top as it is considered a 1st payment after
    >> a plan & payment method change.

    Unless the customer did something I was unaware of, i don't think these things I am listing make sense.
    A. The summary box should reflect the "last payment" amount which is 360 - 96discount = 264, not 0 dollars.
    B. Since the older previous customer subscription had expired, and the new "custom" subscription is now paid for and active, the new one should show at the very top as the subscription active.
    C. The account history is off.

    >> As for the function you were looking at, you may have
    >> overlooked the conditional check it is wrapped in, as
    >> well as the other 2 conditionals in that same function
    >> in pro-sites.php
    I think the programmer has overlooked something...not me :slight_smile:

    I can simply go to: pro-sites-files/gateways/gateway-stripe.php find the line:
    if ( is_pro_site( $blog_id ) && ! $psts->is_blog_canceled( $blog_id ) ) {
    and change it to

    if ( is_pro_site( $blog_id )) {  //ben temp workaround //(&& ! $psts->is_blog_canceled( $blog_id ) ) {

    Doing that and the cancel button shows. So whatever checks you think should have caught it, dont. Because this call to is_blog_canceled is happening.

    Remember this scenario i am discussing is for a blog that was previously cancelled and then reactivated. So when this line ran previously, and saw that it was cancelled, it ran the following line:
    update_blog_option( $blog_id, 'psts_is_canceled', 1 );
    which set psts_is_canceled to 1
    A simple search of the code base shows that the code does not ever remove or set blog option psts_is_canceled to anything else. Here's my search results:

    pro-sites.php:		if ( get_blog_option( $blog_id, 'psts_is_canceled' ) || get_blog_option( $blog_id, 'psts_stripe_canceled' ) ) {
    pro-sites.php:			update_blog_option( $blog_id, 'psts_is_canceled', 1 );
    pro-sites-files/gateways/gateway-paypal-express-pro.php:				update_blog_option( $blog_id, 'psts_is_canceled', 1 );
    pro-sites-files/gateways/gateway-manual.php:		update_blog_option( $blog_id, 'psts_is_canceled', 1 );
    pro-sites-files/gateways/gateway-stripe.php:				update_blog_option( $blog_id, 'psts_is_canceled', 1 );

    In the function, if a blog ID is present
    it runs
    if ( get_blog_option( $blog_id, 'psts_is_canceled' ) || get_blog_option( $blog_id, 'psts_stripe_canceled' ) ) {
    as its first "check", so every time is_blog_canceled will return true once the variable psts_is_canceled has been set.

    There should be no confusion, this is the problem.

    Perhaps the developer is confused because when reviewing the calls psts_stripe_canceled i can see that it can get reset to something other than 1 in other parts of the code. That said psts_is_canceled needs to be reset to 0 or false when a subscription is made active again.

    These tech response take a long time...i really hate hate hate debugging WPMU dev code...please get umesh and more testers on this asap. Its failing and there should be no confusion on the psts_stripe_canceled fail now. Why the user billing page is showing all the incorrect data needs to be tested by your team, i dont know how you can see that as working.

  • Predrag Dubajic

    Hi Ben,

    Our developers are currently checking the code you have mentioned and in the meantime we could use some more information about your setup to better understand this.

    Is this your setup and how the payments went through:
    - First level is $264
    - Second level is $360
    - There's $96 coupon that can be applied to Second level
    - Member signed up to First level and that expired
    - He then subscribed to Second level with the coupon applied

    Is this correct or am I missing something here?

    Could you also grant support access to site in question so we can check your Pro Sites configuration?

    Best regards,
    Predrag

  • Ben

    I'll break all levels down in yearly:

    I have the following levels in the following order
    Baby - 110
    Custom Express - 165
    Custom - 360
    Prev Customer 1 - 264

    User was on "Prev Customer 1" last year.

    Their auto renewal didn't work because their billing source expired or changed or failed.

    They went into their account, signed up for the Custom, and then used a $96 coupon that i gave them to match the same price as Prev Customer 1.

    Hope that makes sense.

    This plugin definitely needs an update both internally and visually! I have opened support