So 3 months after this issue was reported and PayPal became unusable for most people, is it any closer to being fixed?
S2 Button code suddenly not working with PayPal
NO.
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. :{
Sid
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.
Sid
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. 
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.
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.
The big question is - what is absolutely in need of modernization in s2, and how much will it cost to have a good developer change it? I guess maybe 10.000€ for 1. and 2.
In my eyes s2member needs to be changed
-
to never look at signup_vars anymore, and only on the fields that are actually visible in the profile.
-
Move paypal from IPN to API.
-
optional - make it possible to use wocommerce or similar as a frontend for s2member. Keep s2member only for content protection. I think this is much more difficult so would be many many more hours to code.
It will be a lot cheaper if we do 1&2. via a group spending effort than even 1/3 of s2 users moving away to another platform and migrating.
So we pay someone to upgrade s2Member, and then what? Give the upgraded version we all paid for to @clavaque? Pretty sure we can’t just modify s2Member and distribute it ourselves.
I think this is something Cristian needs to do. It’s his plugin. If he wants to continue to sell it, he needs to invest in it.
1 Like
We cannot modify s2member pro, but s2member we can modify and either Christian gives the okay and takes over the modified version - or we use another name. Besides the name it’s okay to resuse s2member (non pro) and distribute it in a modified version.
I don’t see a better way. And both points - stopping all that signup_vars messing around and moving paypal to API are absolutely essential. Especially as a lot of follow up problems are caused by the signup_vars mess (e.g - if you create a new user by hand and mess it up, especially by inserting domain into the wrong field).
I’m willing to chop in 1000€ if both those points are solved. 2000€ should we need to spend over 20.000€ for a programmer to solve this mess.
Would be nice to hear from @clavaque on this issue. If he’s working on this, tell us. And if he’s not, tell us.
1 Like
We can find a much cheaper programmer than that if a student or someone in our community does it. Or maybe someone on Fiverr. It would be important to know what @clavaque is struggling with so we can perhaps focus on that.
I don’t think it’s that easy. I guess it’s 1-2 weeks to move to api, and 1-2 days to program out all the references to signup vars (some are used also on PayPal, but only for initial payment not recurring unlike stripe). And we really want that code well documented - the very good but expensive dev I paid for implementing a vat moss solution in 2015 (based on some now defunct vat service) was complaining badly about the mess of the PayPal code and lack of proper documentation.
But yeah GoFundMe or similar to get the amount together and then hire a dev via a platform is fine.
I think clavaque right now tried to just go for the new ipn version which still leaves loads of mess. A clean modern solution based on API is what we want. So that it’s future proof and easy to adapt on future changes.
At the same time an update to the horrible pro form with a way to define which fields are shown/optional and mandatory would be another possible thing. But that’s not too important. If it goes via API and allows third party checkouts or PayPal generated forms/buttons we don’t really need an improved pro form. Also proform is inside s2member pro so that would cut out s2 member pro .
1 Like
I’m not sure enough money would be raised to upgrade s2Member when there are other plugins in active development.
This entire thread has mostly been a discussion among the same four people, and I doubt even half of those four people would be willing or able to contribute enough.
1 Like
Maybe @clavaque needs to release a newer version of the plugin with a new higher price and give a discount to current s2member pro users.
That might give him more motivation. But I am unsure if that’s the main issue as he’s not interacting in the forum for a while, I guess perhaps he needs time to deal with a personal matter or something unrelated.
Let’s wait a few days to see what he says.
s2Member has been on life support for years. @clavaque is great at general customer support issues but s2Member needs more than that.
1 Like
I believe we’ll figure something out, but it might take us time. Even if it means spending a few months to learn php so we can code something ourselves. Maybe release add ons that integrate with s2member to fix what it can’t do.
It’s been a very long time since I last looked into it but I did not like the pricing model of the other plugins as I think they mostly required a monthly fee or a percentage of the revenue. I don’t want a plugin that holds me hostage, that’s why I like s2member. We make our purchase and even if it glitches here and there, we can keep things running “for free” even if it means doing lots of things manually. I see it as an amateur solution that helps small websites.
I think most people who wanted to purchase this plugin already did it and perhaps there’s not new interest as the plugin is clearly abandoned for a while (not entirely, but mostly).
New potential customers for s2member just move on to other solutions when searching for a membership plugin because they visit the forum and they see it’s outdated.
I think that we can somehow try to bring it back to life. It might require a lot of work, patience, time and perhaps even resources. The code is open, so anybody with enough knowledge could have come in and helped, but this never happened either. I don’t know any php, sadly, or I’d have done it a long time ago, at least on minor issues like s2member’s terrible (lack of) routines around failed payments, demotions and reupgrades upon late payments, for example.
@openmtbmap mentions issues surrounding stripe’s variables that’s another item that needs to be fixed that sounds a bit easier for someone with php knowledge, as I assume it would only require some code modifications to use the fields we can see (sub and customer fields) instead of using the hidden array. Or, at least, show the hidden array on the user profile, even if on a raw format, so we can easily edit it when necessary.