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.

About: Chris Crabtree

Sorry, I've not written a description yet. I'll get to it soon!


Topics I'm Subscribed To

Viewing 4 topics - 1 through 4 (of 4 total)
Topic Count Last Reply
Change PayPal Account:Affects Subscribers?

By:  Chris Crabtree in: Community Forum

voices: 2
replies: 11

4 years ago  Cristián Lávaque

Billing Update Form Not Displaying PayPal

By:  Chris Crabtree in: Community Forum

voices: 2
replies: 2

4 years, 1 month ago  Bruce

PayPal Error #36: Transaction Failed 1 2 3

By:  Chris Crabtree in: Community Forum

voices: 6
replies: 71

4 years, 1 month ago  Cristián Lávaque

Logs for signup process

By:  Chris Crabtree in: Community Forum

voices: 2
replies: 3

4 years, 3 months ago  Raam Dev

Viewing 4 topics - 1 through 4 (of 4 total)

Topics I've Started

Viewing 4 topics - 1 through 4 (of 4 total)
Topic Count Last Reply
Change PayPal Account:Affects Subscribers?

By:  Chris Crabtree in: Community Forum

voices: 2
replies: 11

4 years ago  Cristián Lávaque

Billing Update Form Not Displaying PayPal

By:  Chris Crabtree in: Community Forum

voices: 2
replies: 2

4 years, 1 month ago  Bruce

PayPal Error #36: Transaction Failed 1 2 3

By:  Chris Crabtree in: Community Forum

voices: 6
replies: 71

4 years, 1 month ago  Cristián Lávaque

Logs for signup process

By:  Chris Crabtree in: Community Forum

voices: 2
replies: 3

4 years, 3 months ago  Raam Dev

Viewing 4 topics - 1 through 4 (of 4 total)

My Latest Replies (From Various Topics)

Viewing 25 replies - 1 through 25 (of 32 total)
Author Replies
Author Replies
Posted: Tuesday Dec 11th, 2012 at 5:39 pm #34303

Hey, that’s a brilliant idea. How could I send them to one page after they sign in if their Subscriber ID is empty, and another (the normal page) if their Subscriber ID is populated?

Thanks!

Posted: Friday Dec 7th, 2012 at 3:00 pm #33914

Ah, thank you, you are so right. That makes complete sense now. I need them to create a new subscription under the new PayPal account but under their same user account.

But still, shouldn’t the update billing information page have PayPal as an option regardless? Thinking for once I’m past this, users will need a way to update just their billing info without creating a new subscription, right?

Thanks!

Posted: Thursday Dec 6th, 2012 at 5:39 pm #33798

Just a bit more info: I thought maybe it was a CSS issue and so I looked through the HTML.

On the membership signup page, which does show the PayPal option along with the credit card options as it’s supposed to, there is a card-type-div that contains the different card type labels and radio buttons. The first label/input pair inside that div is card-type-paypal, and the second is card-type-visa, and so on.

On the billing update page, the card-type-div is present again as expected, but this time the first label/input pair inside that div is card-type-visa. There is no card-type-paypal in the HTML source of the entire page.

So it’s definitely not a CSS issue, but looks like an issue with the HTML being generated.

Thanks!

Posted: Thursday Dec 6th, 2012 at 5:29 pm #33795

Thanks, I will take this approach for sure. I will temporarily give existing members a super easy way to get to the update-billing-information page.

And it so happens that my update-billing-information page is not giving PayPal as a payment option…hmmm…I will start another thread as it doesn’t seem related to any of this (I haven’t even changed over the PayPal account yet).

Thanks!

Posted: Wednesday Dec 5th, 2012 at 5:13 pm #33625

Ah, this is encouraging. So I should be able to:

1) Change s2Member’s PayPal information to the new account.
2) Ask existing users to sign in, then go to the Billing Modification page and subscribe with PayPal or a credit card.
3) s2Member will create a new recurring profile for the user under the new PayPal account.
4) I can manually remove their recurring profile from the old PayPal account (via the PayPal site).

Does that sound right?

Posted: Friday Nov 30th, 2012 at 12:59 pm #33023

Got it. Good info. This suggests a method to move these members to the new PayPal account.

1. Stop accepting new members.
2. Set s2Member/Automatic EOT Behavior to Demote.
3. Ask existing members to cancel their subscriptions.
4. Leave s2Member configured for PayPal account #1 until everyone has hit EOT and been demoted.
5. Using Username Changer plugin, change their usernames to _old or something so that when they resubscribe, they can use their original username.
5. Configure s2Member for PayPal account #2.
6. Ask existing member to resubscribe. They can use their original username and will get a new Paid Subscriber ID.

I’m not sure I really want to do all that, but would it work?

Posted: Friday Nov 30th, 2012 at 12:24 pm #33020

Actually, I was going to point out that I don’t think the $0.01 transactions are a good test. Jason did the $0.01 transaction successfully with the exact same settings where the $5.95 transactions were failing.

I don’t think the $0.01 transaction exceeds certain PayPal thresholds and it just approves it. I don’t know exactly where the threshold is for them, but $5.95 definitely equals or exceeds it.

Good tip on the Sandbox; I will avoid that.

I may *never* turn logging off after these last three months. :-)

Thanks!

Posted: Thursday Nov 29th, 2012 at 4:07 pm #32943

Wow, well after all that and a couple more hours on the phone with PayPal, I now have a new PayPal account with PayPal Payments Pro — Payflow Edition (a.k.a. Website Payments Pro), plus Recurring Payments!

So I expect s2Member to work with the new account as designed, since PayPal will (should) allow the BillingType ‘RecurringPayments’ for this API.

PayPal cannot really change the type of an existing account, strangely enough, and they recommended this approach as a workaround. We set up the new account and then they will link the new and old accounts together somehow in a parent/child manner. Or I can transfer out of the old account entirely later and move it all into the new account.

All well and good and I considered going forward with the s2Member configuration changes to reflect the new account IDs and so on, but then realized I have some existing members with existing recurring profiles. I will start a new thread for changing account information and its effect on existing subscribers, so I don’t create a mess out of these members’ profiles.

In the meantime, I’ve disabled new signups until I get it all straightened out, but I am very encouraged that I’ve got the right API on the PayPal side that s2Member expects now. Thanks!

Posted: Monday Nov 26th, 2012 at 2:38 pm #32618

After reading some of the documentation from PayPal MTS about my account type, I think I have realized why this isn’t working for me.

I have Payflow Pro. What I now believe I need is PayPal Payments Pro Payflow Edition, as it supports ‘RecurringPayments’ as the BillingType. Of course I will need the Recurring Billing option as well, but that’s okay by me if I can just get past this issue.

The Billing Type values supported by PayFlow Pro all require a Billing Agreement ID to create recurring profiles, which s2Member today doesn’t support. So I’ve asked to convert my account to PayPal Payments Pro Payflow Edition. We’ll see what they say…

s2Member should, in my opinion, put BAID support on its roadmap for future development so that future customers who end up with a different flavor of PayPal for whatever reason can make things work. At least it would be good to post something in the way of guidance on what specifically to ask for in PayPal so that s2Member will work as is.

Anyway, I will report back.

Posted: Friday Nov 16th, 2012 at 5:14 pm #31832

Hey thanks for trying Mike!

Posted: Friday Nov 16th, 2012 at 4:57 pm #31828

Still need a solution. Going through the logs, the successful PayPal transaction that Jason did mimics the failed PayPal transactions, except of course in the result.

Should We Test The Threshold?
But I wonder if the successful test transaction worked simply because of the tiny difference between the Set Express Checkout amount ($0.00) and the subscription amount ($0.01) asked for later in the process. If PayPal has a threshold between the initial amount and the later amount, as they say they do, then the one-cent transaction may not prove that it ought to work when the difference is larger.

Jason, Cristian, or Raam, if one or all of you would actually sign up for my site using PayPal I’m curious if it would succeed for you as well. It’s only $5.95 and I will of course refund the $5.95 anyway. https://www.phit-n-phat.com/membership-signup

A Good Example?
In the example transaction in the documentation (PayPal Payments Pro Payflow Edition – Recurring Payments Developer’s Guide), it asks for approval of the initial amount during the initial Set Express Checkout request. It then follows that up directly with the Create Express Checkout Recurring Payments Profile Request without the Get Express Checkout Details request in between, which I thought was interesting.

It’s on pages 18 and 19 of that PDF if you’d like to take a look.

Thanks!

Posted: Wednesday Nov 14th, 2012 at 11:52 pm #31659

Looking through the logs, I compared your test transaction to one that failed last night (post-patch). Every step of the way is the same, except the specific IDs are different of course and the final result is failure versus your success.

Still looking for clues, I came across this in the PayPal Payflow Pro Recurring Billing Guide.

When TRXTYPE is R, ACTION is A, and TENDER is P, as it is in the final (failing) step in our process that is trying to create the recurring billing profile, it looks like it’s saying a BAID or ORIGID is required. It says this in the note for the ORIGID field.

NOTE: Either a BAID or ORIGID is required to create
a new profile when TENDER=P.

Now, since we’re not passing either BAID or ORIGID in the failing call to add the recurring profile, I wonder if that has any bearing on our issue. I also can’t explain why it worked for you without these parameters, but I still have to believe there is something wrong here somewhere. Too many customers with different, normally reliable, PayPal setups having issues with my particular site I think is too big a coincidence to just be a coincidence, you know?

Anyway, appreciate your thoughts and continued efforts. Thanks!

Posted: Wednesday Nov 14th, 2012 at 9:25 pm #31648

Thanks for testing it. In my case, my test transaction that failed last night (the first one post-patch) was done by a real client, so there was no funny business going on with a PayPal account buying something from itself.

And when I do test, I do use a separate PayPal account anyway. But that’s nether here nor there.

When we first started getting this error, I thought it had to do with customer PayPal funding sources and surveyed the failing users. It was all over the board, so I ruled out any specific funding source or my account’s ability to receive funding from a specific funding source–like checks.

I expect to find that it’s still the same way, but I have asked the two clients who attempted signup post-patch what their funding sources were. I will report back here.

In any case, where in the world do I tell PayPal that I want to accept checks? I cannot for the life of me find that setting.

Thanks!

Posted: Tuesday Nov 13th, 2012 at 9:31 pm #31529

Also I confirmed in the logs that it is now sending TRXTYPE ‘A’ instead of ‘S’ on the first call, then ‘S’, then finally ‘R’ which is where it fails (as it always has).

I did notice that in the TRXTYPE ‘R’ call, there is an OPTIONALTRX variable that is set to ‘S’ and I wonder if maybe that also needs to be ‘A’? Just a shot in the dark.

Posted: Tuesday Nov 13th, 2012 at 9:00 pm #31524

Same 10422 response.

Posted: Tuesday Nov 13th, 2012 at 8:51 pm #31522

I also applied the patched file and got the same error #36. I have not yet looked in the log files to see if the error code we get back from PayPal has changed.

Posted: Tuesday Nov 13th, 2012 at 5:33 pm #31491

@Jason, I sent your explanation of why a BAID is unnecessary (merchant-initiated versus PayPal-initiated via the recurring profile) verbatim to Graham @ PayPal, who seems pretty knowledgeable I think. We’ll see what he says regardless, but obviously I’m rooting for your recent lead on a fix to get us past this.

Thanks!

Posted: Tuesday Nov 13th, 2012 at 5:06 pm #31487

@Jason, yes, you have my okay to run test transactions to help resolve this matter. Please do what you feel will help best!

Posted: Friday Nov 9th, 2012 at 6:39 pm #31180

On a lark, I sent PayPal support the s2member-log content for a sample failed transaction from a PayPal user. They responded just moments ago, with looks to be very helpful content.

This was their reply.

Thank you for that. The reason it is not working is that they are leaving out a step. The Profile cannot be created without getting a BAID (Billing Agreement ID). This is done after the ‘ACTION = G’ step. To finalize the Express Checkout transaction you would either do an ‘ACTION=D’ to complete with a payment in addition to setting up the profile or ‘ACTION=X’ if you are only setting up a profile. Once the BAID is created you can then run the call to set up the Profile. If you try to do that without finalizing the Express checkout process and getting that BAID it will fail every time.

Please review chapter 2 of the following guide for an understanding of how to get a BAID in the Express Checkout:
https://cms.paypal.com/cms_content/US/en_US/files/developer/PFP_ExpressCheckout_PP.pdf

And also this guide regarding how to use the BAID to create a recurring profile:
https://cms.paypal.com/cms_content/US/en_US/files/developer/PP_PayflowPro_RecurringBilling_Guide.pdf

-Graham

Posted: Friday Nov 9th, 2012 at 5:25 pm #31178

Decided I had nothing to lose by removing the Payflow settings and trying it.

The Good News
PayPal subscription worked perfectly.

The Bad News
Credit card subscription gives Error #11586. DPRP is disabled. DPRP is disabled for this merchant.

So I put the settings back and we’re back at square one.

However, I still contend that s2Member is not using the standard Express Checkout API when Payflow Account Details are filled out. Why?

Well, when I looked at s2member-logs just now, the paypal-api.log has exactly one transaction in it: the successful one I did during the few minutes I had Payflow Details removed.

With Payflow Account Details present, the PayPal transactions are showing up in the paypal-payflow-api.log file (and failing there, as you know).

And again, this may be by design. I don’t know if s2Member is attempting to use Payflow for Express Checkout transactions. If it is, maybe the issue is that whole Billing Agreement ID thing I referenced earlier in this thread from PayPal. If s2Member is supposed to be using the standard Express Checkout API that would show up in paypal-api.log, then it’s not doing that when Payflow Account Details are present.

Posted: Friday Nov 9th, 2012 at 3:48 pm #31169

Let me just ask this again more clearly.

If s2Member PayPal Options/PayPal Account Details are all set up so that it’s integrated with PayPal Pro API, do I really need to also fill out the Payflow Account Details?

In other words, I don’t care about what API is used if my users are able to sign up with credit cards and PayPal and activate their subscriptions. It seems Payflow may not be necessary to do this, and if that’s the case, I actually think it may be causing more harm than good given the results we are seeing currently.

Thanks!

Posted: Friday Nov 9th, 2012 at 3:04 pm #31165

So going back through and parsing all this, I’ve come to the following conclusions on subscription billing.

    1. s2Member is using the Payflow SDK for credit card transactions and this is working.
    2. We think s2Member is using the standard Express Checkout APIs for PayPal transactions, and while there is no reason for this not to be working, it s not.
    3. PayPal themselves say that integrating with the standard Express Checkout API is the best and easiest way to handle users wishing to pay with PayPal for recurring billing. This avoids the whole Billing Agreement dance.

Question
Is there a way to confirm #2 via the logs or in the code itself? I realize s2Member ‘Free Edition’ already does this, but I wonder if the Payflow SDK settings are taking the code down a different path as an unintended side effect.

Since Mike tried the PayPal-only ProForm and had it fail, I have not done so as I expect the same result. I am happy to try it as well if you still think it would give us some insight.

Thanks!

Posted: Wednesday Nov 7th, 2012 at 11:23 am #30909

I am not getting the IPN failing problem, just to disambiguate.

Posted: Tuesday Nov 6th, 2012 at 5:42 pm #30805

Very interesting response from PayPal today. After confirming that Express Checkout was live in my PayPal account, I decided to use my open channel with PayPal support to ask them to double check from their end that it was indeed setup correctly. Here is what I wrote to them:

My software vendor (s2Member) is telling me that it *does* use Express Checkout when the customer wants to pay with PayPal, and asked me to confirm that Express Checkout is indeed enabled on my account.

When I go to PayPal Manager, it says that Paypal Express Checkout has a Status of “Live” and a Mode of “–“. So does that confirm that it is enabled or is there somewhere where you guys or I should be checking other than my PayPal Manager Service Summary?

Since I’ve been having these issues, I would appreciate a verification on your side that Express Checkout really is enabled, just in case the UI is showing me one thing but the account is not fully configured to allow Express Checkout or something weird like that.

Thanks!

This is what PayPal support wrote back.

The Express Checkout will always be enabled for use, if you have a Payflow account with PayPal as the processor. The issue you are encountering would have to do with your shopping cart’s integration of the Payflow Express Checkout for the Recurring Billing.

If you go through and create a profile using a credit card, all you have to do is make a transaction and then refer to that transaction with the transaction ID, to create a profile. You cannot do that with an Express Checkout transaction ID. You have to create a Billing Agreement transaction which would generate a BAID (Billing Agreement ID) and that is used in place of the Transaction ID to create the profile.

I don’t think your cart is trying to do the implementation that way, and that is why they are having issues. If you can have them send in a copy of the string they are posting to PayPal I can take a look at it to see what it is that they are doing wrong.

-Graham

So when the user chooses Express Checkout, is s2Member creating this Billing Agreement transaction to acquire the BAID so that the profile may be created? Or is it trying to process the same path as credit card transactions where there is no Billing Agreement?

I suppose I could look through the code for clues, but would really appreciate it if someone more familiar with the code could do so and get me (us) a definitive answer. Maybe this is the root of the whole problem.

Speaking of which, *is* there anyone familiar with the code other than Jason or is it a one-developer show here at s2? Just curious.

Thanks!

Posted: Monday Nov 5th, 2012 at 4:41 pm #30680

Could you confirm that you have Express Checkout enabled in your account?

Yes, in PayPal Manager, under Service Summary, it lists Express Checkout with a Live status. Here is the full set of services:

Service/Status/Mode
PayPal Payments Pro/Live/–
Hosted Checkout Pages/Live/–
Payflow SDK/API (Full Access)/Live/–
Recurring Billing/Live/–
Paypal Express Checkout/Live/–

Thanks!

Viewing 25 replies - 1 through 25 (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.