Howdy everyone,
Has anyone successfully integrated with Paypal's marketplaces and platforms methods? I have spent the last few weeks struggling to complete the 'live' integration. My 'sandbox' integration works great, but when I remove the word 'sandbox' from the endpoint I am not able to onboard a new seller. Instead of getting api response I am sent an html page.
<html>
<head>
<title>400 Bad Request</title></head>
<body bgcolor="white">
<center><h1>400 Bad Request</h1></center>
<hr><center>Avi Vantage/</center>
</body>
</html>
To sanity check this, I setup the call in Postman which works just fine. As such, I know that the token I create as well as the endpoint is good. It has to be something with my ability to contact api.paypal.com via Web Connection. Just to reiterate, if I send exact same call to the 'sandbox' endpoint it works as it should, when I remove the word 'sandbox' from the endpoint I get the html page instead of api response. I am in fact creating a new 'token' each time I make a call (one for each endpoint, sandbox or live)
https://developer.paypal.com/docs/platforms/seller-onboarding/before-payment/
Any thoughts?
Make sure you're setting the content type (application/json?)on the request.
+++ Rick ---
Funny you should mention that. While coding in sandbox mode and trying to do refunds I was NOT able to do a refund because when I used
lohttp.cContentType = "application/json"
The refunding process failed. I then setup the call in Postman and it worked fine. By process of elimination I eventually discovered that I had to add this:
lohttp.addheader("Content-Type","application/json") && took two weeks to figure this out
The WWWC framework essentially does the same thing, but I guess essentially is the wrong word, since it solved the refunding problem.
Sadly, your suggestion and this solution did not solve my 'partner on boarding' issue.
I will make sure I am using the latest version of wwRequest / wwResponse.
Does the version of wc.dll play any part in this or perhaps some TLS stuff?
Oh cContentType most definitely works. But most likely you're setting nHttpPostMode after setting the content type which will override that setting.
+++ Rick ---
I wish that was it.
Can we schedule a paid call on Monday? I am at my wits end over this.
ps: The ridiculous thing is that it works fine when I set my app to 'demo' mode which does one thing (changes the endpoint at paypal to sandbox vs live. No other code changes.
I will try fiddler first and reply back.
Well, this is quite interesting. I installed fiddler 4 and turned on the sniffer. First time through it did not work. Meaning, fiddler did not even capture request. Fiddler complained about my https setup. I foolishly did not take a screenshot to share, but I dumb user'd it and just kept clicking around. I restarted Fiddler and the OS asked if it could install a Telerik cert. I said ok.
Then paypal api stuff worked straight away.
My servers must have some ssl issue.
ps: The ridiculous thing is that it works fine when I set my app to 'demo' mode which does one thing (changes the endpoint at paypal to sandbox vs live. No other code changes.
My experience is usually the opposite. The SandBox is all bonked up but production tends to usually work. The shitty thing about this is that you try to hunt down a non-existing problem only to find out it would have just worked.
Always try things both in SandBox and Live (if possible) and check the differences.
+++ Rick ---
Rick,
Thanks for hanging in there with me, as it seems you might be the only kindred spirit out there that has endured this Paypal drama. I should mention that I have had tickets open with Paypal for weeks and not a single one thought to suggest that the 'server' may be the issue. My servers are Windows 2016 cloud servers hosted at vultr.com. Each server has a Godaddy wildcard ssl cert on it that is valid.
Checkout the series of screenshots that show first the problem, then the screens that Fiddler 4 show after a fresh install, and then finally the problem resolved. I have a feeling you will write an article about this after you see what is happening.
Goal - visit a Paypal eCommerce Platform on boarding url. The first screenshot below is my custom WWWC page that attempts to connect a 'seller' to my companies Partner account.
The next series of screenshots show what Fiddler 4 does by default when installed on the WWWC app server.
And then finally, after restarting Fiddler 4 (this was important) my page loads. Problem solved.
I am sure there is a way to script this issue with Powershell but I am still not sure what the issue is. In the end I discovered this page at Paypal which has the obvious clues. Paypal Security Tips
I hope this helps someone who may have wasted a huge amount of time. The lesson in all of this is that if you are doing integration work with third parties, be sure to install Fiddler! I was using Wireshark which did not discover this so quickly.
This reminds me of an incident with Microsoft Support of Office 365 where I think they had some kind of Fiddler and in order to work it did this thing with all of my certificates and renamed them all something like 'DO_NOT_TRUST_
Rather than even trying to deal with all of the messed up certs on my machine I restored a system image onto the C drive and all was relatively well. Microsoft credited me some money back since this was part of my Office 365 subscription. And MS said that they were developing some internal tool to use instead.
So, take a look at your certs and make sure they are ok.
Thanks Jeff. I would say all looks great (famous last words). The issue of course is that my dev server works as expected now, but I have to roll it out on production, and I do not think installing a tool like Fiddler on a production server makes much sense 'just to be able to charge credit cards'. Seems more like a newb solution that will lead to a future hack or exploit.
The article I found at paypal is most certainly the clue, but after doing what they suggest and rebooting each time, still no luck (on a server running my wwwc app that does NOT have Fiddler installed).
Fiddler will mess with the Certificate chain in order to inject the proxy and decrypt HTTP traffic. It won't work with everything. For example, DropBox and OneDrive don't work when Fiddler is hooked up. It's possible the same is true with PayPal. Basically there are checks that see if a proxy is in use and if it is the requests are aborted.
If Fiddler is not enabled all those certs it installs (one for each site you proxy) are not used and they won't interfere with anything. They are installed into the current user chain so you can easily delete them by selecting and removing them - they'll come back once you start using sites again but if you use Fiddler a lot it's a good idea to nuke all of them. I think the other thing you can do is turn off SSL Decryption in Fiddler and it'll remove the certs it installs as well.
+++ Rick ---
Rick - I just re-read your response. Did you perhaps misunderstand me? I am saying that when Fiddler is running, my WWWC app CAN connect to api.paypal no problem. If I turn fiddler off I cannot connect. I thought installing Fiddler was all it took but the app has to be running with the settings I showed you in the screenshots. Also when I use postman on the same server (without Fiddler running), I am able to reach the paypal api no problem.
I had a look this morning in the wwHttp class and discovered this
IF this.lIgnoreCertificateWarnings
This caused me to do some proper hacking and I came across this article -
I tried adding INTERNET_FLAG_IGNORE_REDIRECT_TO_HTTPS thinking perhaps i could set a mode for just my paypal calls to ignore these issues, but I could not compile my app once I did. I assume you have to add that to wc.dll ?
Have you enabled loopback authentication on the server? Perhaps there's some local authentication that's happen and causing problems.
Windows Authentication Errors on local Servers (Loopback Protection)
+++ Rick ---
Rick - I was so excited to try it - but check this out.
Windows PowerShell
Copyright (C) 2016 Microsoft Corporation. All rights reserved.
PS C:\Windows\system32> New-ItemProperty HKLM:\System\CurrentControlSet\Control\Lsa -Name "DisableLoopbackCheck" -Value
"1" -PropertyType dword
New-ItemProperty : The property already exists.
At line:1 char:1
+ New-ItemProperty HKLM:\System\CurrentControlSet\Control\Lsa -Name "Di ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : ResourceExists: (HKEY_LOCAL_MACH...Set\Control\Lsa:String) [New-ItemProperty], IOExcepti
on
+ FullyQualifiedErrorId : System.IO.IOException,Microsoft.PowerShell.Commands.NewItemPropertyCommand
PS C:\Windows\system32> New-ItemProperty HKLM:\System\CurrentControlSet\Control\Lsa -Name "DisableLoopbackCheck" -Value
"0" -PropertyType dword
New-ItemProperty : The property already exists.
At line:1 char:1
+ New-ItemProperty HKLM:\System\CurrentControlSet\Control\Lsa -Name "Di ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : ResourceExists: (HKEY_LOCAL_MACH...Set\Control\Lsa:String) [New-ItemProperty], IOExcepti
on
+ FullyQualifiedErrorId : System.IO.IOException,Microsoft.PowerShell.Commands.NewItemPropertyCommand
PS C:\Windows\system32>
well it looks like it is set to 0 explicitly, so see if you can set it to 1 manually. Then log off and back on.
+++ Rick ---
I have edited this message a few times, the long story short is 'PROBLEM SOLVED' - yahoo! I realized only this morning, that other calls to the paypal api LIVE server were in fact working from my platform. Once I realized that, it was then obvious that only the specific call mentioned at the top of the thread (seller on boarding [the step 1 in the workflow] ) was failing. I simply compared the calls I was pushing on an 'order' vs what I was pushing on an 'on boarding' and made them the same. It then worked. Here are the tags that must be sent for Paypal Partner On boarding.
loHttp = Createobject("wwHttp")
lohttp.addheader("Authorization",'Bearer ' + lcAccessToken) && received from PP
lohttp.addheader("Content-Type","application/json")
loHttp.addheader("Accept","*/*")
loHttp.addheader("Accept-Encoding","gzip, deflate, br")
lohttp.addheader("Prefer",'return=representation')
lohttp.addheader("PayPal-Partner-Attribution-Id",m.lcBnCode) && created by PAYPAL
lohttp.addheader("PayPal-Request-Id",m.lcPaypalRequestId) && created by me
lohttp.addheader("PayPal-Client-Metadata-Id",m.lcPaypalClientMetaDataId) && created by me
lohttp.AddPostKey("",tcJson)
m.lcUrl = [https://api.paypal.com/v2/customer/partner-referrals/]
_cresult = lohttp.HttpGet(m.lcurl)
Rick,
Sorry to say, I thought I had this issue resolved, but I still do not. The quick summary is this. When I turn on fiddler, my app works, when I turn off fiddler it fails. It fails due to some SSL issue. I can confirm that my server does not have any old TLS running, and subsequent calls to paypal work fine. It is just the one call that gets a user started on their ability to connect their paypal account to my WWWC platform.
In the screenshot below you can see what when this one call is made from my WWWC app to paypal, that paypal requests a client certificate to be sent. For some reason my server does not send a certificate, but Fiddler does. That should be the only clue we need to know to send me down some path to repair this.
I installed openssl and tried to connect to api.paypal.com and I get the following. Note the obvious error "unable to get local issuer certificate" - I spent lots of time with all sorts of articles on the web to no avail. I can also confirm that if I make the call to api-sandbox.paypalc.com it all works fine (without fiddler).
C:\Users\sophio>openssl s_client -connect api.paypal.com:443 -showcerts
CONNECTED(0000018C)
depth=2 C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert Global Root G2
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=1 C = US, O = DigiCert Inc, CN = DigiCert Global CA G2
verify return:1
depth=0 C = US, ST = California, L = San Jose, O = "PayPal, Inc.", OU = PayPal Production, CN = api.paypal.com
verify return:1
