PayPal Error #36: Transaction Failed

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.

Still getting the error as well, after installing the patch.

• This reply was modified 4 years, 1 month ago by  Tony Schwartz.

Thanks for the follow-ups.
~ I’m taking a look at your log files now.

@ Chris Crabtree

A test transaction has been performed on your live site against the PATCHED version. In my test, a monthly recurring subscription to your site was paid for via PayPal Express Checkout and the Payflow API. The test was successful, and the results are recorded in the log file: /s2member-logs/paypal-payflow-api.log

@ Tony Schwartz

A test transaction has been performed on your live site against the PATCHED version. In my test, a monthly recurring subscription to your site was paid for via PayPal Express Checkout and the Payflow API. The test was successful, and the results are recorded in the log file: /s2member-logs/paypal-payflow-api.log

@ Mike Whitney

I was unable to run a test transaction on your site today. The WP Dashboard login that I have for your site is no longer functional. If you’d like us to run a test transaction on your site, please submit a new Dashboard login for me here: s2Member® » Private Contact Form

---

In short, I’ve been unable to reproduce the issue under the PATCHED version running on any of your installations. However, I HAVE found entries in each of your log files, supporting your follow-ups regarding the same error #36, and the accompanying 10422 error code.

I also noticed that at least two of the log entries are referencing what *appears* to be test transactions that you submitted yourself (i.e. as the owner of the site, not as a customer). If problems persist, I would try submitting a test transaction again, and this time pay with a PayPal account that is NOT the same one being used to carry out transactions on your site. That is, don’t try to buy something from yourself via PayPal.

That *could* be the only remaining issue at this point (which is a known limitation on the PayPal side of things). Transactions via PayPal will fail if a site owner tries to purchase something from the same PayPal account that is configured to power s2Member.

Also, please remember to check your PayPal account configuration and make sure that the PayPal account you’re paying with is funded by a credit card. If it’s funded by a checking account, or by GiroPay, your PayPal account will need to be configured to allow these types of transactions. This can be accomplished in your PayPal account profile.

Please report back with any additional findings. So far I’ve been unable to reproduce the issue under the PATCHED installations.

Regarding OPTIONALTRX.

My test transactions were submitted with OPTIONALTRX=S in the final API call, and in agreement with the underlying API documentation, this is being submitted correctly. It’s a Sale amount, and OPTIONALTRX should be set to S, as it is being set by s2Member Pro. No issue here that I’m aware of.

Hi Jason,
Created another log-in for you.

Sent PCF.

@ Mike Whitney

Thank you.

A test transaction has been performed on your live site against the PATCHED version. In my test, a monthly recurring subscription to your site was paid for via PayPal Express Checkout and the Payflow API. The test was successful, and the results are recorded in the log file: /s2member-logs/paypal-payflow-api.log

Please refer to my earlier post and let me know if you have any further trouble.
http://www.s2member.com/forums/topic/paypal-error-36-transaction-failed/page/3/#post-31638

Ok thanks Jason!

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!

Jason,
I still cannot get this working with my different PayPal accounts. I’ve gone into both my PayPal accounts and set available funding sources to credit cards. I’ve un-clicked my bank accounts. I still get the same error. I don’t know why it works for you. I’ll have a friend try with their PayPal account.

Can I ask two questions?

1) When you got past your PayPal log-in screen does it give you any options to select funding? Mine always says default payment. Which like I said I changed in Paypal.
2) When you tested you used the PayPal Pro form?

This is the shortcode I’ve been testing with:
[s2Member-Pro-PayPal-Form level="1" ccaps="test" desc="$.50 USD / Monthly ( recurring charge, for ongoing access )" ps="paypal" lc="" cc="USD" dg="0" ns="1" custom="www.websiteaddress" ta="0" tp="0" tt="D" ra=".50" rp="1" rt="M" rr="1" rrt="" rra="2" accept="paypal,visa,mastercard,amex,discover,maestro,solo" accept_via_paypal="paypal" coupon="" accept_coupons="0" default_country_code="" captcha="0" /]

• This reply was modified 4 years, 1 month ago by  Mike Whitney.

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!

Update from me:

Jason I found your PayPal Pro form test payment page and it has the same style shortcode as mine, so disregard that question.

I also contacted PayPal and they let me know they have IP security in place which would explain why my payment fails. I was trying to make a test payment on the same computer as the seller and payer. Apparently they will block that.

I will try later from a different source and report back.

Thanks.
Mike

Hi again Jason,

I’ve given up calling PayPal. Since your transaction was fine I can only assume there are problems with both my PayPal accounts. After calling them three times today they suggested I create a Sandbox account. I don’t understand why I would since it worked for you. I was merely calling them to find out why my transactions on my accounts failed. I thought there was some setting in my accounts as to default payment or something that needed changed. It seems so clear their entry level people answering the phones are not trained well enough to answer questions relating to this nature and I don’t have any more time to work on this.

Unless somebody else is still having problems I guess we need to consider my case closed for now.

When my site is completely live and somebody makes a purchase I guess we will find out.

Thanks.
Mike

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!

Hi Chris,
I tried just for fun and it failed same error.
But I’m still left thinking there is something wrong with my PayPal accounts.

Mike

Hey thanks for trying Mike!

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.

I have Payflow Pro. What I now believe I need is PayPal Payments Pro Payflow Edition

Chris, yes, that’d be a problem, since PayFlow Pro is not supported by s2Member yet. That’s why I mentioned earlier in the thread, explaining that PayPal Pro PayFlow Edition is supported, but it’s PayPal Pro, not PayFlow Pro.

PayPal has caused a tremendous amount of confusion to users with their dumb choices for names and the way they mixed their services with similar names…

s2Member should, in my opinion, put BAID support on its roadmap for future development

We plan to support PayFlow Pro in the future and if BAID is required for that, it’ll be supported too.

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!

Well done for straightening that out! I’m sorry you went through that, but we can’t do much about PayPal’s ways. :/

When you test the configuration with the new PayPal account, please do live 1 cent transactions, better not to use the Sandbox (another troublemaker).

Keep logging enabled and let us know how it goes! I hope all well. :)

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!

Glad to help! :)

Thanks for the tip on the 1 cent transactions! I didn’t know that. Well, it’s still worth to use them for the main testing battery, but then do one with the actual price you’ll be charging, to make sure no problems arise from that. Always good to test the actual thing the customer will be experiencing.