I looked this up, and their documentation says
- As long as SOLUTIONTYPE=Sole is passed in the SetExpressCheckout API, Guest Checkout will be enabled.
s2 sets that value in s2member-pro/src/includes/classes/gateways/paypal/paypal-checkout-in.inc.php
$paypal_set_xco["SOLUTIONTYPE"] = "Sole";
So the change/cause is elsewhere, most likely in some undocumented change they made to the API…
I hope the new API will be more reliable. 
This was another one I loved:
Pretty sure it didn’t say that 3 months ago.
I have hope the new api will be better - on the simple member site we used to test, it worked beautifully.
I don’t know how many members sales our people can afford to lose before they cancel with us.
Sid
I think in Europe it doesn’t yet.
But don’t your users actually prefer to use a PayPal account instead of typing their credit card information directly? Otherwise, you can use Stripe forms for them.
And, if you still face issues with PayPal buttons not working, you can just create manual ones as a temporary solution using PayPal’s “dumb code/links”. That will require you to edit the user profile on your site (or even create it) manually, though. It’s ok for small sites (I just did it), not good if you run a large operation. 
@clavaque for the Love of God I can’t take much more of this!
WHY is this Pro-form shortcode:
[s2Member-Pro-PayPal-Form level=“2” ccaps="" desc=“Full AI Site Membership - $8.72/month” ps=“paypal” lc="" cc=“USD” dg=“0” ns=“1” custom=“deadeasysoftware.com” ta=“0” tp=“0” tt=“D” ra=“8.72” rp=“1” rt=“M” rr=“1” rrt="" rra=“2” accept=“paypal” accept_via_paypal=“paypal” coupon=”" accept_coupons=“0” default_country_code="" captcha=“0” /]
Displaying THIS form
with Credit Card Logos we are losing paying members because they click the ■■■■ credit card logos but the form crashes!
Sid
What happens if you change the switch to force people to have a PayPal account (I know it’s not ideal, but would that work as a temporary fix for you?)?
That is just it - we ARE forcing no CC on site by setting these shortcodes
accept=“paypal” accept_via_paypal=“paypal”
So @clavaque - or ANYBODY - how do we get rid of these buttons? If users select one, a credit card form appears - if they fill it out and hit [submit form] INSTANT ERROR
Sid
Shouldn’t it be ps="paypal" accept="paypal" accept_via_paypal="paypal" ?
Also, your screenshot seems to be from a mobile (not too wide), how does it look for desktop users?
That IS how it’s set - I just forgot the 3rd one. It’s ALL just “paypal”
It IS on a desktop - I just cropped/reduced the picture.
TESTED it on tablet and iphone - ALL show the full list of button choices.
My CTO says he believes different things (with the old SOAP API) are happening - with the same s2 code - depending which of PayPal’s dozen or so server farms are handling the incoming transaction.
But THIS error is all s2 - haven’t left the site yet.
Sid
Interesting because that is enough for my site to not show the cards but I do not have PayPal Payments Pro (can’t even sign up for it here in Europe).
Same thing with a Canadian account I used for testing. Only PayPal as a payment is available that way.
Did you test those three things I listed (I think you didn’t use the ps=“paypal”, it seems to be the only difference).
Now, while I don’t get the problem you do, even when a user uses the PayPal’s checkout properly, PayPal is NOT collecting any money and sending the user back to the page they came from (I tested it). @clavaque saw that behavior when he tested things on my site.
I think he’s working on a new version that uses the new API but we need to give him enough time to code it, he’s likely rewriting the entire thing.
Meanwhile, can you use legacy buttons? Or even PayPal links generated by PayPal itself for subscriptions? If you don’t have a large amount of traffic that might work, be advised it involves tons of manual processing, subscriber per subscriber. Since I get very few, I can handle it, it might be a bad solution for you, even if temporary, though, but perhaps better than having no subscriptions at all?
Can’t you use Stripe? It works fine here.
Maybe leave a not on top of your form letting them know that even though there’s a choice to type their credit card info, they won’t be able to use it and they have to choose the first? It’s a but unprofessional but they would comprehend you’re experiencing temporary technical difficulties.
Just a few ideas, of course, sorry if not good ones.
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.
Sid
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”
Instead
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.
Sid
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. 
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?
Sid
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
@clavaque We fixed it. AFTER 4 days of trying various things.
We discovered:
You MUST use the “generate shortcodes” button and paste that code
THEN and ONLY THEN make changes or additions (such as the “success” feature)
BUT
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
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.
Sid
@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.
Sid
@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.
Sid