S2 Button code suddenly not working with PayPal

AS I said we DO use ps=“paypal” I just forgot to put it in the reply here.
ALL relevant codes are set to only paypal

And we are just using the s2 Pro form -we do NOT have “PayPal Pro” accounts. None of our clients do either.

We have 93 site we own an manage - we are building 200 more.
ALL of them have s2. Doing all this manually would be a nightmare.

And we TESTED manual buttons - it has ERRORS on the return to the site. Post variable can not be verified and users CAN NOT REGISTER.

So even if we wished to do it all manually - we don’t! - it would be even worse to have to manually create all those accounts!

NONE of our sitemasters clients have stripe accounts - neither do we! (Lost a LOT of money thanks to stripe 2 years ago).

And this is taking too long. Especially when the ■■■■ s2 pro Form has people choosing credit card options that are not even supposed to even be there and instead of signing up people are getting pissed.


Well, considering your massive size isn’t it more cost effective to hire your own dev on fiverr or something?

The money you already lost would have been enough for you to (sub)hire someone to customize s2member code to your needs and make it work.

I get you don’t want to spend it but waiting for an official solution here will very likely still take a long time.

If you want good and fast you need to pay more. Solutions like s2member are clearly designed for small website owners that can’t pay for a professional grade solution designed for large scale.

Frankly, we kept waiting for a fix, but it has been nearly 2 MONTHS.

The issue now would be not just the cost of a developer (who can figure s2 out), but the time it would take to GET a solution.

PLUS we found ANOTHER issue with s2 pro forms.

Even IF a user ignores the credit card icons (that are not supposed to appear - the Problem I posted before)
and correctly selects “PayPal” on the pro-form
(the pro-form page we call “register” because they register for their account before paying),
and goes thru PayPal payment process successfully
he is NOT sent “back to the site gracefully
he is sent to BACK to THE SAME “register” page with a URL such as:


since that is the registration and payment page, the user thinks he has to pay twice!

So any developer hired would have to fix that as well.

This issue here could also be - like others - buried in the interchange between s2 and the ‘new’ PayPal or old API, but the fact is it has to be fixed.

No matter how many wonderful things s2 - or any membership system - may offer, a broken payment processing system makes all that irrelevant.


1 Like

Yes! This is the behavior I mentioned several days ago which made the PayPal form unusable (Stripe form works normally, btw).

User is sent back without paying and without registering.

@clavaque is already looking into it and he did some tests.

I don’t know when he will be able to fix it, there’s a new update for the plugins today (basic and pro). I will check the changelog and test things if the issue is included in it.

Thanks @lavarock7. Sadly, it would not work. Well, I could surely risk it but then if someone chooses the non resident (or even if I use the user’s geoip after learning how to filter it) while having an EU PayPal account I’d have a massive headache to deal with, hence why it’s easier to charge the tax and refund manually until I figure something out. Hopefully most people will choose Stripe. And, of course, I only have a handful of subscribers anyways, so I can do those things manually, after all. :slightly_smiling_face:

Actually since mid July, another bug happens way more often on paypal than before - and that is users after payment on paypal getting a broken auto-return.

If you enable logging then look for Unable to verify $_POST vars inside gateway-core-rtn.log (actually look for that bug in all other logs too, It’s lease serious here and way worse if it appears in the other logs however). It’s only in this regard that it’s happening more often now however.

We reported the broken auto_return weeks ago. On ALL 93 sites we were/are seeing it.

It has not been fixed - of course it may be mute if the PayPal bug is fixed and using the new API.

There is also an unfixed bug in the pro form - it still displays a credit card form even if set to ONLY PayPal for everything,
and the CC form actually crashes the pro form with errors when users “submit” the pro form, since it is set for PayPal only and NOT for “on-site” credit card entries.

None of these have been fixed. Maybe the PayPal fix is expected to fix all of this?


1 Like

I don’t know why you’re getting the cards shown if the shortcode attribute only has “paypal”. It could happen if s2’s javascript is not loaded, but then other things are shown, too.

I couldn’t reproduce it on my tests site. I also couldn’t reproduce it on the site you sent me:

I’m not sure where you’re getting those card options, I don’t see them in your /register or /register-yearly pages:


In any case, if the paypal option is selected by default, you could hide that section with CSS. Your CTO will know how:

#s2member-pro-paypal-checkout-form-billing-method-section {display: none !important;}

The default return is to the same page. You can change it with the success attribute for a custom redirection, e.g. success="/my-thank-you-page/". See: WP Admin > s2Member Pro > PayPal Pro-Form > Custom Return URLs Upon Success

1 Like

@clavaque We fixed it. AFTER 4 days of trying various things.

We discovered:

  1. you can not just put (such as copy&paste) pro form shortcode on a page or it will always produce a default page. AND ignore certain settings, such as the accept settings. This was NOT really explained in docs

You MUST use the “generate shortcodes” button and paste that code
THEN and ONLY THEN make changes or additions (such as the “success” feature)


Even IF you use the button, if you change certain shortcodes - like the original set PRICE or the “default country code” it will again generate a DEFAULT (we assume) form that IGNORES things like the setting of accept="paypal"in the short codes

This combination of factors caused all the issues we saw.

We did not use the generate button for all the tests/form creations and were adding and deleting short codes at random and getting different looking forms where we didn’t expect.

The DOCS for the pro forms need a LOT of fleshing out and extra information (like where the hell does it tell you, when trying to customize a template, what %%custom_options%% are/include/use, etc.)

BUT @clavaque

I have seen updates to s2 BUT NOT FOR THE MOST CRITICAL ISSUE

  • Fixing PayPal usage/issues and the New API

WHEN, please, is that going to happen. It has been 3 MONTHS since we started seeing and reporting the paypal issue!

Do you have ANY estimate of when we will see PayPal fixes / new API? I really don’t think that is an unreasonable question.


1 Like

@clavaque WHEN are we going to see the Paypal fix with the new API?

We got an email from PayPal Merchant Tech Support today “encouraging” us to start using the new API "as soon as possible"

They also said the NEW API is the ONLY way to fix the glitch that prevents the user from being able to use his PayPal balance for Subscriptions.


1 Like

@clavaque what does this new Pro Forms error mean. I need to know NOW please

error #10002 Security Error. Security header is not valid

It did work, on the same site, 2 days ago.

I took logs, and logs show the API info matches what is in the paypal account API.


So 3 months after this issue was reported and PayPal became unusable for most people, is it any closer to being fixed?

It is still flaky. If you set s2 to NOT use encrypted buttons AND pro forms (they do NOT require a PayPal Pro account), they work, BUT to weird things like NOT allow paypal users to pay a subscription with their paypal balance.

WE LOSE 1 out of every 4 potential subscribers because of that (based on complaints to us)

PayPal Merchant Support (who I have talked to on the phone about 50 times1) say it is because we are using the old partially-deprecated IPN system.

@clavaque is supposedly working on a version using the new API PayPal STRONGLY encourages us to use, but nothing has happened there in 4 months. Not even a time estimate.

Not much else I can tell you there Stephen. :{


1 Like

Not that I’m seeing replies, but what those THIS pro form error mean?

Invalid form configuration. Invalid “custom” attribute. Must start with matching domain.


1 Like

I solved my biggeset problems resulting from s2member IPN misconduct by now switching quaderno.io to directly go via paypal as third party data processor instead of forwarding IPN information once s2member has processed it. Yes I think this will cause a 1-2minute delay on payment until account active - but that’s not a problem at all vs s2member for various unknown reasons dropping one payment alltogether every 200 payments or so or being unable to handle paypal complaints, chargebacks and so on correectly (meaning account active until money refunded, while deactivating account if money not arrived instantly and so on).

Actually a full rework of paypal should be dropping IPN alltogether and instad directly log payments happening on paypal as it’s way more reliable. Quaderno.io has since done everything 100% correctly while s2member has it’s fair share of errors.

The best would be if s2member drops IPN and goes for a modern data processing in paypal - the same way that quaderno.io or other modern plugins do. Then we could even use 3rd party paypal checkout implementations or paypal generated buttons and whatever - and all that antiquated code from s2member could be removed making that part of s2 that causes so many problems and failures over the last years (yeah since I’m using this plugin - so since 2011) obsolete and instead focus on it’s core strength which is content securing - which s2member does very well.

Don’t go for the modern version. A rework of just using paypal generated buttons or forms and then s2member simply logging paypal activity would be the real solution.

I’m thinking that maybe we should just pool together a gofundme and look for someone that can program this? Modern solutions don’t use IPN and interact directly with paypal and stripe. For paypal this is rather new - for Stripe this has been possible since years. Then just use s2member for securing content but drop it’s payment part alltogether. Quaderno.io has a much harder job of identifying what happens with payments, refunds, chargebacks and so on - but it does so 100% correctly on Stripe since 2016 for me, and now since 1.5 months not a single ever error on paypal while s2member had over 15 signup_vars mess up problems in those 1.5 months.

1 Like

I wonder if you’re related to that service provider as you frequently “advertise” it. :grimacing:

Meanwhile, basic buttons don’t seem to be working anymore either.

PayPal gives a page with the product name allowing for the user to type in any price.

Sadly I think s2Member’s days as a complete membership solution are coming to an end unless someone can figure out how to upgrade the payments side of it.

While it should not be up to us to find the answers, clearly @clavaque lacks either the skills or the interest. So for s2 to survive, someone else needs to step in.

In the 3+ months since this issue was first reported, I probably could have learned enough PHP to at least help with the solution, so I don’t know what the heck @clavaque is doing.

1 Like

I don’t know either, I hope he’s ok. Sometimes people struggle with personal problems and get overwhelmed, I guess?

I did the best I could, including a couple of donations towards the project.

I didn’t have enough time to invest learning PHP, but I considered it, that would be helpful one way or another, maybe sometime in the future.

Meanwhile I am just using “dumb” buttons created by PayPal, then I manually update each profile and upgrade each user. Can’t use PayPal for new subscribers that are registering, they must use Stripe or register as free users and upgrade later.

That’s the advantage of having a very tiny micro website, I guess? I’d have moved on or learned how to fix it if I had enough flow, but as it’s not the case I just do things manually. :grimacing:

Thankfully PayPal still works for me, but I think it’s because I pay the monthly PayPal fee and I only sell one-time memberships.

BUT… if PayPal suddenly stops working, I’m gone. While I hate the thought of having to learn a new plugin and migrate my members, I need to earn money, and there is no indication that s2Member will ever be upgraded.

no, I have no affilation with them except using their services for invoices. Actually if you know any other service that does this reliably for cheaper (OSS is all I need) I’m very interested, as their services are really not cheap (and as I used it until 1.5 months behind s2 IPN, and only if s2 successfully handled the IPN it would be forwarded - I on one hand had to write quite a few invoices manually, on the other hand would very easily see all the s2 malfunctions as no invoice (I queried it with a database vs paypal/stripe transaction lists) meant s2 had bugged something up beforehand. So that way I noticed all those signup_vars problems - it was always signup_vars never any other error - and clavaque hasn’t ever found the error for most of those problems if I forwarded him all the logs - signup_vars is the huge dirty blackbox of s2member.

For me my own paypal button still works as usual - just without encryption. But the problem is that 1 out of ever 200-300 payments ends up in s2member signup_vars nirvana. Meanin customer pays, and either cannot create an account or doesn’t receive the notifcation emails from s2 (or some other bug like can register but will see a huge error notice).

The problem is not using another plugin, the problem is another plugin correctly handling your old customers on recurring payments. It should be much better now as IPN is phased out and plugins can integrate directly into paypal via API - but not sure which membership plugin makes use of that already. But if it’s possible to create invoices, cancel invoices and get all the relevant data via API (for Stripe that’s possible since the start, for paypal I think since 2 years or so) than it makes it much easier. The IPN and forwarding it for other services or websites/domains or similar is just too limited.