latest stable versions: v150827 (changelog)

Old Forums (READ-ONLY): The community now lives at WP Sharks™. If you have an s2Member® Pro question, please use our new Support System.

Chris Crabtree

My Latest Replies (From Various Topics)

Viewing 7 replies - 26 through 32 (of 32 total)
Author Replies
Author Replies
Posted: Saturday Nov 3rd, 2012 at 6:02 pm #30571

So I tried to clarify further with PayPal, sending them this:

1. So it sounds to me like I should use the Express Checkout API for PayPal-using customers to do the recurring billing for the subscriptions. Correct?
2. Can I also use the Express Checkout API to process credit card-using customers as well?


PayPal’s response:

Those are good questions.

You would use the Payflow Gateway Version of Express checkout to create a billing agreement (see chapter 2 of the guide: Then you can create a profile off the BAID (Billing Agreement ID)that is generated through that process to create the recurring profile in Payflow.

You cannot use the Express Checkout to create profiles with a credit card, they would have to have a PayPal account.


I’m hoping this will be more helpful for you guys than it is to me, but thought I should pass it on. I’m not getting from this that there is anything I need to do as far as *configuring* s2Member or PayPal goes. But I’m happy to try things if you have suggestions. Hopefully looking through the logs will be the ultimate answer.


Posted: Saturday Nov 3rd, 2012 at 5:59 pm #30570

Also, I’m trying to keep the conversation with PayPal going, and have a couple more tidbits that may prove useful to us.

Here is the first bit. I posted back to them:

Okay, but why then would *some* PayPal paying signups work successfully, even though *most*, almost all, failed as we’ve been discussing?

Here below are some Transaction IDs of successful signups who paid with PayPal. Some of these are Verified members and some Unverified.



And then PayPal’s response:

As I said, it may charge the account before it creates the profile, but the profile will not be charged the next time around. In all other circumstances the profile is attempting to be created before the charge is completed, that results in the error, which would be the intended result.


What this says to me is that even those PayPal users who *did* appear to successfully sign up for the subscription actually did not. They get the first billing period, and then when the time comes for the recurring charge it will fail. This in fact just happened today with one of my early “invited guest” test subscribers. She got a PayPal notice of subscription cancellation and cannot today access the site.

It all points back to the order of profile creation and billing API used for the different paytypes if I am following PayPal’s explanations correctly.

I will post the next bit of the conversation separately. Thanks!

Posted: Saturday Nov 3rd, 2012 at 5:53 pm #30569

I sent the PCF as well just now. Thanks!

Posted: Friday Nov 2nd, 2012 at 1:21 pm #30478

Any thoughts as to a solution or a workaround here?

We are postponing our launch beyond the few existing invited members waiting on this single issue at this point.


Posted: Monday Oct 29th, 2012 at 6:42 pm #30101

Actually, the funding sources were all over the map (visa credit, mastercard credit, discover credit, debit, checking, checking primary credit secondary, etc.), so I didn’t find any common denominators there.

However, PayPal finally responded and after a bit of back and forth, this is what they told me:

That is completely understandable. I do have to apologize though, I just realized how it was that you were attempting to set up these profiles with .

With Payflow you can only set up profiles with credit card transactions. You could use the recurring options through the standard Express Checkout APIs or use the Express Checkout through Payflow to create Billing Agreements, then bill accordingly. I think the options to do it through the standard APIs would be the easiest to develop.

The profiles that have been created will fail when PayPal is used as the funding source. The profiles can be created but the way Payflow references credit cards for the recurring portion will not work with PayPal as the funding source.

So does this mean s2Member should be doing something different, or does this point back to the workaround we discussed of simply removing the Payflow API parameters and letting s2Member fall back to the older APIs? Or something else entirely?


Posted: Friday Oct 26th, 2012 at 3:45 pm #29865

Yes, the 10422 referral is exactly what I’m getting.

Payment Receiving Preferences Ruled Out
When I first noticed the problem and researched it a couple week ago, I set my Payment Receiving Preferences so that Block payments sent to me in a currency I do not hold is set to No, accept them and convert them to primary currency. I just checked and it’s still set correctly, so we can rule that out.

Accepted Card Type Information — maybe?
In the post you linked to, I inferred from what Jason said that if a customer’s funding source was a checking account, but your merchant account was not accepting checks, then that could cause the problem. This seems like a good thing to check, so within PayPal Manager, I went to Processor & Merchant Bank Information/Accepted Card Type Information to find the card types my account is currently accepting:
PayPal Express Checkout
American Express

And since PayPal Express Checkout is on the list, it seems to imply that it should work, but I’m not certain.

I’m still looking for a way to explicitly “Accept Checks” if that’s the problem. Most of the customers who are getting the PayPal Error #36 I’m sure have their checking or savings account linked to PayPal and not a credit card. So that could totally explain it.


Posted: Monday Sep 17th, 2012 at 12:32 pm #25582

The server check script is a great idea. I ran it and it found that PHPMailer throws an exception: possible email delivery failure, and in fact, the email did not arrive, so that is definitely a problem although obviously it isn’t related to “Invoice has already been paid” or “User registration is not currently allowed” messages.

The only other issue was a notice that the WP_MEMORY_LIMIT was only 32M instead of the 64M.

So I asked WPEngine to help me correct these two, and also to turn off caching on the signup page. I think disabling the caching may help the real issues here, but we’ll see.

No users have accounts at this point on the site, so the already-logged-in scenario doesn’t exist, so we can safely rule problems related to that out of the picture.

Is there a way (outside of s2member) you know of with WordPress to “follow” a user’s path through the site so I can see that they arrive at the signup page, click to go to PayPal and then, sometime later perhaps, show back up on the registration page, proceed to login, etc.? Is there a plugin that will do this or would I have to set up Google Analytics or CrazyEgg or something to do this?


Viewing 7 replies - 26 through 32 (of 32 total)

Old Forums (READ-ONLY): The community now lives at WP Sharks™. If you have an s2Member® Pro question, please use our new Support System.

Contacting s2Member: Please use our Support Center for bug reports, pre-sale questions & technical assistance.