Protected Content - Free Trial, Collect Payment Info at Signup

I'm using the Protected Content plugin, and I've setup 2 paid membership subscriptions that bill monthly, using PayPal as the payment gateway. But, when I add a 14 Day Free Trial to each membership, new users are able to register & add a membership without submitting payment information.

What should happen is that when users sign up, they're still required to enter payment information, so that after their 2 week free trial expires, they're billed automatically - unless they cancel.

Please let me know how to fix this, and/or tell me what you need to help me address this issue.

  • Adam Czajczyk

    Hey Tim,

    I hope you're well today and thank you for your patience!

    I've got this message from our developers team that says that this is "by design" behavior. This is caused by how the payment gateway works. As their system doesn't allow pre-authorize transaction that's more than 7 days in future, such an action would cause a lot of invoicing issues.
    Actually, the members would be able to pay for their memberships a few days before trial expiration but technically this is working as intended.

    If you have any further questions, please ask. I'll be glad to assist!


    • tim_kassouf

      Thanks for the other comment of support on this Trent... I just read through the thread that you linked to above, though, and wanted to share my thoughts (as well as some general frustrations!!) on that... I hope it's helpful in one way or another...

      From everything I've read, it COULD be "by design" if you're using the "PayPal Single Gateway" - because I believe that particular payment gateway isn't designed to schedule recurring payments... I believe that with that particular gateway, it simply sends recurring bills - but payment information isn't collected because there's no payment authorization that's meant to remain open for recurring monthly payments.

      However, that should only be the case in that one, very limited, scenario! I've tested this with Stripe & "PayPal Standard Gateway" (the one I'm trying to use now) and it's the same error everytime - the plugin is clearly calling the WRONG gateway at the point of payment...

      Additionally, I've found that users who go through this broken system still don't actually get membership access!! (Which again proves that it CANNOT be by design!!) It appears that, because the system is still expecting to receive confirmation that payment/authorization has been made via PayPal, the user that has signed up isn't actually then put into any membership group! On the admin side, in the "Billing" section of "Protected Content", their invoice status shows as "Billed" - not "Paid" - so the users can't even access the content for the membership that they've just been told they signed up for...

      This needs to be rectfied ASAP; I'm quickly losing faith & trust in WPMUDev... I've been an ardent supporter of this group, the tools they create & the content they share on their blog for years. I've referred several colleagues to their plugins & themes, and I'm sure I could trace at least a dozen members to my recommendation... But, now, I have a major problem - I'm missing go-live deadlines, I have a client that's hemorrhaging money every single day this isn't resolved, and just when I need the premium support that I've paid for - all I've gotten is very lackluster support, so far:

      First, they say it's "by design" (which makes NO sense except MAYBE in one isolated circumstace - and they didn't even explain that detail, I had to figure that out on my own - which is why I'm not even sure it's correct.) So then, I'm left to research & dig into this as deeply as possible on my own, and lo & behold! I actually identify the precise issue for them! Great! Should be handled very quickly now, right?!?! I've yet to even get a response since I revealed these details to them... Nothing! This is literally killing my client's business! He's a great guy who has his life savings & his family's future wrapped up in this business...

      I'm VERY hopeful that something magical will happen & that the WPMUDev team will come through very soon... But in the meantime, the only option I have is to explore other membership plugin options that will be able to handle this functionality (which really is a rather basic functionality element for a plugin like this). But obviously, going with a new plugin is no small feat! MUCH of this site & CSS is literally built around the "Proteced Content" plugin - and I'm already in the process of starting to rebuild everything, just because this stupid bug & their failure to help is leaving me with no other option... I can't sit idly by & do nothing!!

      My fingers are crossed, but my hopes are fading... Please help us WPMUDEV!!!

      Sorry Trent - I might've gotten a little off the rails there, but I'm passionate about how major this is... And I think we both really deserve the support that we NEED!

  • tim_kassouf

    That can't be correct... The PayPal Standard Gateway absolutely allows monthly subscription billing - I've been able to create PayPal "buttons" that process this type of payment - including with the appropriate free trial period before the billing begins... Here's a link to process a transaction via PayPal that works exactly as it should be working through this plugin:

    In fact, as I've dug deeper into the issue, I've found that part of the problem is that the link provided for users (after registering & when picking the membership) isn't the correct link for the gateway that I've selected. For example, I've setup the PayPal Standard Gateway, and for the "Payment button label or url" I've entered "Subscribe Today!" (see this here: However, on the front-end of the site, when a user selects a membership, then registers, the page that they're taken to shows a button with the word "Signup" - not what I'd specified in the settings. (Here's a screenshot of what users see:

    However, if I enter a broken link into the "Payment button label or url" field in settings, the Register page will show a broken image where the button should be (meaning it is correctly pulling in the right payment gateway button). And, when I proceed with a registration via this broken image button - the payment processes as intended via PayPal! Obviously, I can't leave a broken image icon in there, but when I swap it out with regular button text, the system is again NOT calling up the correct payment gateway... I've been unable to consistently recreate the process by which it was working properly, but I can prove that it did by showing you this screenshot from PayPal ( where you can see that a recurring payment was successfully created (then cancelled) then created again via my other PayPal account (under the name Adornable Jewelry).

    The more compelling argument however is that the wording chosen for the Payment Gateway's "Payment button label or url" is NOT showing up on the front end of the site... Instead, the only thing that will show up is the default label.

    If we can correct this issue - so that the site will call the correct payment gateway with that button press, I'm confident the issue will be resolved. Please tell me what else you need from me to address &/or resolve this issue.

  • Adam Czajczyk

    Hello Tim,

    I hope you're well and thank you for this more than in-depth analysis!

    In my previous post I've forwarded you a message that I've received from our 2-nd line support team. Obviously, it seems like we missed something here and your tests show a path to further investigation. Having said that, I've notified the developers about your findings and I hope we'll be able to come up with a solution fast.

    Please keep an eye on this thread!


    • tim_kassouf


      I'm not sure if you missed my most recent post, but I'd definitely appreciate an update, or at least a response to my post from May 6 at 12:52:11 pm.

      In addition to that, I've also clarified 2 other important points in a reply to Trent above... (1 - Testing w/ an additional payment gateway & 2 - Why new users don't have access to the protected content after they signup via this process). Rather than have you hunt for that in my other post, here are the relevant details:

      1) I've now tested this with Stripe & the "PayPal Standard Gateway" (which is the one I'd like to use ultimately) & I get the same error, regardless of the gateway that's activated: when a free trial is turned on, the plugin is clearly pulling in the WRONG gateway at the point of payment.

      2) And now, I've found that users who attempt to signup through this broken system don't actually get membership access even though the site just told them that they signed up! (Which again clarifies that this is a bug & simply cannot be by design!) I'm assuming that, before the system will grant the user access, the plugin is still expecting to receive confirmation that payment/authorization has been made via the activated payment gateway - even though it never passed the user to that gateway for payment processing.

      These are the details to support that assumption: On the admin side, I can see the new user & I can see that they're listed as a member under the correct membership (so it's not an issue of the user account not being created, nor is it an issue with them not being added to the correct membership). But, in the "Billing" section of "Protected Content", their invoice status shows as "Billed" - not "Paid" - and while that setting remains, the users can't access any protected content despite being correctly listed as a "member" under that membership (and despite the message they received after signup saying that registration was successful). Once I change the invoice status to "Paid" though, that user does have access to the content.

      Ultimately, I think this is just more fallout from the original bug - which, again, is that at the point of payment, the plugin is incorrectly using a "Free" gateway instead of the payment gateway that's been activated - only when a free trial is active for a membership.

      This is killing my client's business - really causing irreperable harm - and it's clearly hurting mine as well, so getting this fixed is a MAJOR priority for me... I'm willing to do anything I can to help, so please just let me know what I can do to support this effort - and please, please pass along my urgency in finding a solution for this!! I really need your help, and I'm flat out desperate at this point.

      Thank you!

    • tim_kassouf


      As I continue to investigate this issue, I think I've actually isolated the issue in the code... (Obviously, I could be wrong, but since I continue to hear nothing back, this is the best I can do!)

      I downloaded the plugin & have been following the logic of the code, and here's the issue that I might have uncovered...
      In this file: 111137_protected-content-\protected-content\app\controller\class-ms-controller-gateway.php
      On line 291, a public function called "purchase_button" starts. This is within that function on lines 297-300 :

      $is_free = false;
      		if ( $membership->is_free() ) { $is_free = true; }
      		elseif ( 0 == $invoice->total ) { $is_free = true; }
      		elseif ( $invoice->uses_trial ) { $is_free = true; }

      This would appear to set $is_free to "true" if the invoice total equals $0.00 or if the the invoice uses a free trial. Then, this appears later on lines 313-318, starting with the comment that starts on line 313:

      // Free membership, show only free gateway
      			if ( $is_free ) {
      				if ( MS_Gateway_Free::ID !== $gateway->id ) {

      If the variable $is_free is set to true - which it will be if the invoice is $0 or a free trial is used - then the plugin only shows the "Free Gateway".

      This is the EXACT problem! The plugin should NOT automatically use only the free gateway when the invoice = $0 and/or there's a free trial offered!

      I'm not 100% sure that this is true for all payment gateways, but I'm positive that it's the case for the Paypal Standard Gateway - where PayPal itself handles the free trial & at the point of signup, it collects payment info & creates an ongoing subscription that will bill the user monthly once the trial is completed. Once this subscription is created with valid payment information, the Paypal Standard Gateway passes that payment authorization back to the site - even if the initial payment was $0 because of a free trial. And this step is CRITICAL for the site to work as intended - where payment info is collected up front & automatically billed once the trial has expired.

      Again, just to show this to you, here's a link to process a transaction via PayPal that works exactly as it should be working through this plugin:

      There might be a better or more complete solution, but at a minimum, you could do this: After line 300 (where the function checks for the value of the invoice and/or whether it uses a trial), have this function check to see if the Paypal Standard Gateway is active, and if it is, then just set the variable $is_free back to "false" - since the free trial will be handled by the gateway itself & doesn't need to be handled by the plugin. (This would only work if it's done after line 300 and before line 313.)

      So, now that I've clearly identified the issue - and even found where in the code the problem exists, can you please have your development team resolve this immediately?!

  • tim_kassouf

    Here's even more information, including difinitive proof that the issue isn't "by design" as you suggested... It's quite clear that when a Free Trial is activated, the plugin is forcing the signup process to use the wrong Payment Gateway, even though I only have the PayPal Standard Payments gateway active or even setup on the site!

    When I get through the registration setup, it takes me to the confirmation page that should link me out to PayPal - here's a screenshot of that page, with developer tools activated... You can see on this screenshot that it's pulling in CSS for "gateway_free" & showing the word "Signup" for the button:

    Now, when I remove the Free Trial, that same page shows that it's pulling in CSS for "gateway_paypalstandard" & shows that it's showing the words "Subscribe Today" for the button (as it should be doing, even with the free trial):

    Just for kicks - here's a video walkthrough of the only circumstance where I'm able to get the site to work correctly... (and it DOES work correctly). Basically, I have to remove the free trial on the admin side, then on the front-end get to the page in the process that I was screenshotting above. Once I'm there, I go back & add the free trial on the admin side & on the front-end, I refresh the browser... This adds the free trial back to that final registration page, but keeps pulling in the correct gateway! So, when I click through, it sends the correct info to PayPal (a 14 day free trial, followed by an autopayment of $29/mo)! This is exactly how it SHOULD work!! Unfortunately, when I logout & try to run through the process again - it's back to pulling in the WRONG gateway. (Here's my little video screencast:

    Please help me fix this ASAP. Everyday that the plugin isn't working is killing my client!!

  • Adam Czajczyk

    Hello Tim and Trent,

    I hope you're well today!

    As I've said before, we definitely need some developer's help here, especially in reference to your recent analysis. I've already made a relevant notification but please give a little more time to analyze the code and the issue. I have also updated our 2nd-line support team with recent information from you, so hopefully this will speed-up things.

    Kind regards,

  • Jack Kitterhing

    Hi there @tim_kassouf,

    Hope you're well today.

    I've been testing this and debugging most of this evening to make sure I'm not missing anything, but I can't replicate this issue, first I'll explain a bit of background of why the system works like this.

    Originally in Protected Content we had it so that payment info was collected at signup, (PayPal, Stripe etc). But unfortunately trials with Stripe don't work very well, as any trial over 7 days couldn't be captured as a pre-auth, resulting in a immediate charge to the clients credit or debit card.

    Because of this we changed it to the current system whereby payment isn't required until trial expiration.

    The current workflow and status should be: > Register >> Pick Membership >> click signup >> enter user details >> complete signup >> success message.

    The invoice will show the membership status as "trial" with the date the trial ends and the invoice status as billed, not paid, which is correct.

    The member should then have full access to all content which is allowed by that specific membership.

    I've checked with both PayPal single, standard, Stripe and, as well as on Single site and multisite, I've also checked the code for logic issues and haven't found any within regards to how trials are designed to work.

    I'd be more than happy to allow you access to my test site, on which you can see it working on a un-modified version of the current production release of Protected content.

    Would it be possible for you to send me the following details so I can debug what is happening on your site?

    Can you please send in:
    - In the subject field add "Attn: Jack Kitterhing
    - Link back to this thread
    - Include admin/network access
    - Include FTP
    - Include database access (I can then check the relevant user meta).
    - Include any relevant URLS for your site

    On the contact form, select "I have a different question", this ensures it comes through and gets assigned to me.

    Thank you!

    Kind Regards

Thank NAME, for their help.

Let NAME know exactly why they deserved these points.

Gift a custom amount of points.