PayPal REST API: Requesting oauth token returns 500 - paypal

Two days ago, something broke with our paypal integration. Unfortunately, trying to contact paypal support has proven to be of no help (no reply in 2 days), so I'll try my luck, here.
Requesting the token (curl https://api.paypal.com/v1/oauth2/token -H "Accept: application/json" -H "Accept-Language: en_US" -u "****:****" -d "grant_type=client_credentials") started ALWAYS returning an empty response and well, a 500 error.
Note that the same works just fine with api.sandbox.paypal.com and sandbox credentials.
I double checked our credentials and they are fine. Note as well, that it doesn't matter what credentials I use, it always returns the same - 500.
Here's the output of curl ... -v; looks like you have an internal server error, as the 500 shows:
* About to connect() to api.paypal.com port 443 (#0)
* Trying 173.0.88.98...
* connected
* Connected to api.paypal.com (173.0.88.98) port 443 (#0)
* successfully set certificate verify locations:
* CAfile: /usr/ssl/certs/ca-bundle.crt
CApath: none
* SSLv3, TLS handshake, Client hello (1):
* SSLv3, TLS handshake, Server hello (2):
* SSLv3, TLS handshake, CERT (11):
* SSLv3, TLS handshake, Request CERT (13):
* SSLv3, TLS handshake, Server finished (14):
* SSLv3, TLS handshake, CERT (11):
* SSLv3, TLS handshake, Client key exchange (16):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSL connection using DES-CBC3-SHA
* Server certificate:
* subject: C=US; ST=California; L=San Jose; O=PayPal, Inc.; OU=PayPal Production; CN=api.paypal.com
* start date: 201
* expire date: 201
* subjectAltName: api.paypal.com matched
* issuer: C=U
* SSL certificate verify ok.
* Server auth using Basic with user '****'
> POST /v1/oauth2/token HTTP/1.1
> Authorization: Basic ****
> User-Agent: curl/7.27.0
> Host: api.paypal.com
> Accept: application/json
> Accept-Language: en_US
> Content-Length: 29
> Content-Type: application/x-www-form-urlencoded
>
* upload completely sent off: 29 out of 29 bytes
* additional stuff not fine /usr/src/ports/curl/curl-7.27.0-1/src/curl-7.27.0/lib/transfer.c:1037: 0 0
* HTTP 1.1 or later with persistent connection, pipelining supported
< HTTP/1.1 500 Internal Server Error
< Server: Apache-Coyote/1.1
< Date: Thu, 28 Mar 2013 15:59:53 GMT
< Content-Length: 0
< Connection: close
<
* Closing connection #0
* SSLv3, TLS alert, Client hello (1):
Thanks!

This is something that is currently being looked into. If you have not already opened a ticket with PayPal MTS I would advise opening up a ticket with Technical Support, so that your issue can be added to the examples. You will also then be notified once the issue has been resolved.
edit: This is now resolved as of 04:12 AM GMT (31/03/2013).

Related

API Gateway Returns HTTP 413 For GET Requests With No Body

My application is receiving an HTTP 413 "Request Entity Too Large" response from AWS API Gateway when sending a GET request to download a file.
While the requested file is > 29 MB in size, that is returned in the response, of course. As I understand it, an HTTP 413 pertains to the body of a request.
Why would API Gateway be returning an HTTP 413 if there is no body in the request?
Below are details from a curl command of the same URL my application uses.
curl -v https://api-gateway-host.us-east-1.amazonaws.com/path/to/file
* Trying <IP address>:443...
* Connected to api-gateway-host.us-east-1.amazonaws.com (<IP address>) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
* CAfile: /etc/ssl/cert.pem
* CApath: none
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256
* ALPN, server accepted to use h2
* Server certificate:
* subject: CN=*.execute-api.us-east-1.amazonaws.com
* start date: Aug 24 00:00:00 2022 GMT
* expire date: Sep 22 23:59:59 2023 GMT
* subjectAltName: host "api-gateway-host" matched cert's "*.execute-api.us-east-1.amazonaws.com"
* issuer: C=US; O=Amazon; OU=Server CA 1B; CN=Amazon
* SSL certificate verify ok.
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* Using Stream ID: 1 (easy handle 0x7f8fed80d400)
> GET /path/to/file HTTP/2
> Host: api-gateway-host.us-east-1.amazonaws.com
> user-agent: curl/7.77.0
> accept: */*
>
* Connection state changed (MAX_CONCURRENT_STREAMS == 128)!
< HTTP/2 413
< date: Thu, 27 Oct 2022 21:43:06 GMT
< content-type: application/json
< content-length: 38
< apigw-requestid: arw4qjGbIAMEMugqerq=
< vary: Origin
< vary: Access-Control-Request-Method
< vary: Access-Control-Request-Headers
< x-content-type-options: nosniff
< x-xss-protection: 1; mode=block
< cache-control: no-cache, no-store, max-age=0, must-revalidate
< pragma: no-cache
< expires: 0
<
* Connection #0 to host api-gateway-host.us-east-1.amazonaws.com left intact
{"message":"Request Entity Too Large"}
Also, this same application, located in a different environment (QA), can make these same kinds of requests for the same file successfully.
The config has only one stage ($default), the route (ANY /path/{proxy+})integrates with an ALB, and has no authorizations.
I have reviewed the API Gateway configurations of the two environments, but cannot find any differences.
Thanks for your help!

Can't fix Paypal "invalid_client" authentication error

I'm trying to test my Paypal integration from localhost using Paypal Sandbox, but whenever I try to get an access token from Paypal, I get back the following error:
{
"error": "invalid_client",
"error_description": "Client Authentication failed"
}
I make the request with curl:
curl -v https://api.sandbox.paypal.com/v1/oauth2/token \
-H "Accept: application/json" \
-H "Accept-Language: en_US" \
-u "clientId:secret" \
-d "grant_type=client_credentials"
Obviously I am using the actual client id and secret in the request, and I am SURE I am using the correct client id and secret for the sandbox environment (I double checked).
Curl's verbose logs look like this:
curl -v https://api.sandbox.paypal.com/v1/oauth2/token \
> -H "Accept: application/json" \
> -H "Accept-Language: en_US" \
-u "clientId:secret" \
> -d "grant_type=client_credentials"
* Trying 173.0.82.78...
* TCP_NODELAY set
* Connected to api.sandbox.paypal.com (173.0.82.78) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:#STRENGTH
* successfully set certificate verify locations:
* CAfile: /etc/ssl/cert.pem
CApath: none
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Request CERT (13):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Certificate (11):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Client hello (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS change cipher, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256
* ALPN, server did not agree to a protocol
* Server certificate:
* subject: C=US; ST=California; L=San Jose; O=PayPal, Inc.; OU=PayPal Production; CN=api.sandbox.paypal.com
* start date: Jul 27 00:00:00 2020 GMT
* expire date: Aug 1 12:00:00 2022 GMT
* subjectAltName: host "api.sandbox.paypal.com" matched cert's "api.sandbox.paypal.com"
* issuer: C=US; O=DigiCert Inc; OU=www.digicert.com; CN=DigiCert SHA2 High Assurance Server CA
* SSL certificate verify ok.
* Server auth using Basic with user 'clientId' // The original log has the actual clientId here
> POST /v1/oauth2/token HTTP/1.1
> Host: api.sandbox.paypal.com
> Authorization: Basic QVRQZGl5TTFqeXpQZkdxMW9FQ2xnZG1uUE13VDRQM01yZEJ1MGRGWVZGLWRNVjk1X09xVjZVam1nNU5xRC0wR2ZPT1I3U1ZianYybWQzQXc6RURQSVdoREpPM0dkdndYNVlRaG45QzRCYzBlUTctaEpWZ041ZlVjUlpkbG1Ta0pMelhzZXE0TmpXeEZMV3kwcGdBNE5zTE5MZ1Qyc0pBVW0=
> User-Agent: curl/7.54.0
> Accept: application/json
> Accept-Language: en_US
> Content-Length: 29
> Content-Type: application/x-www-form-urlencoded
>
* upload completely sent off: 29 out of 29 bytes
< HTTP/1.1 401 Unauthorized
< Cache-Control: max-age=0, no-cache, no-store, must-revalidate
< Content-Length: 77
< Content-Type: application/json
< Date: Wed, 07 Apr 2021 08:57:50 GMT
< Paypal-Debug-Id: 891f84363e502
< X-Paypal-Token-Service: IAAS
<
* Connection #0 to host api.sandbox.paypal.com left intact
{"error":"invalid_client","error_description":"Client Authentication failed"}
The problem seems to be here:
ALPN, server did not agree to a protocol
I have NO idea what it means. Could this have something to do with the fact that I'm testing from localhost? How can I fix this?
Decoding the base64 in the verbose log, the client ID passed is ATPdiyM1jyzPfGq1oEClgdmnPMwT4P3MrdBu0dFYVF-dMV95_OqV6Ujmg5NqD-0GfOOR7SVbjv2md3Aw
This does not work when testing at https://developer.paypal.com/demo/checkout/#/pattern/client , so it is not a valid ID.
( Link showing the error, "client-id not recognized for either production or sandbox" )
Create a new REST app, https://www.paypal.com/signin?intent=developer&returnUri=https%3A%2F%2Fdeveloper.paypal.com%2Fdeveloper%2Fapplications

HTTP/2 with Ubuntu 18.04

I would like to try HTTP/2 on this site: https://www.alebalweb-blog.com/
I recently updated the server to Ubuntu 18.04 with PHP 7.2, Apache/2.4.29, etc,etc
I did: sudo a2enmod http2
Added:
#HTTP/2
Protocols h2 h2c http/1.1
In my VirtualHost SSL.
and restarted Apache.
The SSL certificate is provided by Let's Encrypt.
The result is:
curl -k -v --http2 https://alebalweb-blog.com
* Rebuilt URL to: https://alebalweb-blog.com/
* Trying 45.76.70.142...
* TCP_NODELAY set
* Connected to alebalweb-blog.com (45.76.70.142) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
* CAfile: /etc/ssl/certs/ca-certificates.crt
CApath: /etc/ssl/certs
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Client hello (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-CHACHA20-POLY1305
* ALPN, server accepted to use http/1.1
* Server certificate:
* subject: CN=alebalweb-blog.com
* start date: Jul 7 02:02:06 2018 GMT
* expire date: Oct 5 02:02:06 2018 GMT
* issuer: C=US; O=Let's Encrypt; CN=Let's Encrypt Authority X3
* SSL certificate verify ok.
> GET / HTTP/1.1
> Host: alebalweb-blog.com
> User-Agent: curl/7.58.0
> Accept: */*
>
< HTTP/1.1 200 OK
< Date: Fri, 13 Jul 2018 21:51:22 GMT
< Server: Apache/2.4.29 (Ubuntu)
< Upgrade: h2,h2c
< Connection: Upgrade
< Cache-Control: max-age=300
< Expires: Fri, 13 Jul 2018 21:56:22 GMT
< Vary: Accept-Encoding,User-Agent
< Transfer-Encoding: chunked
< Content-Type: text/html; charset=UTF-8
Really strange I think is this:
Upgrade: h2,h2c
Connection: Upgrade
What does it mean?
HTTP/2 Test says:
HTTP/2 Test Result www.alebalweb-blog.com
Negative! www.alebalweb-blog.com does not support HTTP/2.0.
ALPN is not supported.
I feel like I missed something big... can you help me understand what?
I think I solved by switching to PHP-FPM
I used these codes:
apachectl stop
apt-get install php7.1-fpm # Install the php-fpm from your PHP repository. This package name depends on the vendor.
a2enmod proxy_fcgi setenvif
a2enconf php7.1-fpm # Again, this depends on your PHP vendor.
a2dismod php7.1 # This disables mod_php.
a2dismod mpm_prefork # This disables the prefork MPM. Only one MPM can run at a time.
a2enmod mpm_event # Enable event MPM. You could also enable mpm_worker.
apachectl start
from this guide: https://http2.pro/doc/Apache
and this guide: https://techwombat.com/enable-http2-apache-ubuntu-16-04/
and added "Protocols h2 h2c http/1.1" at the end of /etc/apache2/apache2.conf
Now the command curl -k -v --http2 https://alebalweb-blog.com reports this:
curl -k -v --http2 https://alebalweb-blog.com
* Rebuilt URL to: https://alebalweb-blog.com/
* Trying 45.76.70.142...
* TCP_NODELAY set
* Connected to alebalweb-blog.com (45.76.70.142) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
* CAfile: /etc/ssl/certs/ca-certificates.crt
CApath: /etc/ssl/certs
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Client hello (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-CHACHA20-POLY1305
* ALPN, server accepted to use h2
* Server certificate:
* subject: CN=alebalweb-blog.com
* start date: Jul 7 02:02:06 2018 GMT
* expire date: Oct 5 02:02:06 2018 GMT
* issuer: C=US; O=Let's Encrypt; CN=Let's Encrypt Authority X3
* SSL certificate verify ok.
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* Using Stream ID: 1 (easy handle 0x556ec5957940)
> GET / HTTP/2
> Host: alebalweb-blog.com
> User-Agent: curl/7.58.0
> Accept: */*
>
* Connection state changed (MAX_CONCURRENT_STREAMS updated)!
< HTTP/2 200
< date: Thu, 19 Jul 2018 20:21:38 GMT
< server: Apache/2.4.34 (Ubuntu)
< cache-control: max-age=300
< expires: Thu, 19 Jul 2018 20:26:38 GMT
< vary: Accept-Encoding,User-Agent
< content-type: text/html; charset=UTF-8
Above all you notice this changes: ALPN, server accepted to use h2, and HTTP/2 200
The site https://tools.keycdn.com/http2-test, says:
Yeah! www.alebalweb-blog.com supports HTTP/2.0.
ALPN supported.
And the development tools of opera and chrome indicate: h2
I only have one last doubt, in Google Webmaster tools, fetching the page as Google, I see this:
HTTP/1.1 200 OK
Date: Thu, 19 Jul 2018 20:35:35 GMT
Server: Apache/2.4.34 (Ubuntu)
Upgrade: h2,h2c
Connection: Upgrade, Keep-Alive
Cache-Control: max-age=300
Expires: Thu, 19 Jul 2018 20:40:35 GMT
Vary: Accept-Encoding,User-Agent
Content-Type: text/html; charset=UTF-8
Content-Length: 41422
Keep-Alive: timeout=5, max=100
I missing something? Or maybe need time?

PayPal Rest first call won't appear in sandbox transactions

I want to have a transaction that is completed and see it listed in my developer sand box. I think this transaction, below is completed but it is not in my sandbox transactions list. I followed the instructions on the paypal website for making a first call with the rest API.
Here are my two curl commands using my credentials and the returned access token. I received my state:created for the payment. But the transaction was not in my Sandbox Transactions. How long does it take to show up?
What am I doing wrong?
Thanks,
Harry
curl -v https://api.sandbox.paypal.com/v1/oauth2/token \
> -H "Accept: application/json" \
> -H "Accept-Language: en_US" \
> -u ".....:....." \
> -d "grant_type=client_credentials"
* About to connect() to api.sandbox.paypal.com port 443 (#0)
* Trying 173.0.82.78... connected
* successfully set certificate verify locations:
* CAfile: none
CApath: /etc/ssl/certs
* SSLv3, TLS handshake, Client hello (1):
* SSLv3, TLS handshake, Server hello (2):
* SSLv3, TLS handshake, CERT (11):
* SSLv3, TLS handshake, Request CERT (13):
* SSLv3, TLS handshake, Server finished (14):
* SSLv3, TLS handshake, CERT (11):
* SSLv3, TLS handshake, Client key exchange (16):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSL connection using AES256-SHA
* Server certificate:
* subject: C=US; ST=California; L=San Jose; O=PayPal, Inc.; OU=PayPal Production; CN=api.sandbox.paypal.com
* start date: 2012-12-06 00:00:00 GMT
* expire date: 2016-12-06 23:59:59 GMT
* subjectAltName: api.sandbox.paypal.com matched
* issuer: C=US; O=VeriSign, Inc.; OU=VeriSign Trust Network; OU=Terms of use at https://www.verisign.com/rpa (c)10; CN=VeriSign Class 3 Secure Server CA - G3
* SSL certificate verify ok.
* Server auth using Basic with user '......'
> POST /v1/oauth2/token HTTP/1.1
> Authorization: Basic .......... =
> User-Agent: curl/7.22.0 (x86_64-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3
> Host: api.sandbox.paypal.com
> Accept: application/json
> Accept-Language: en_US
> Content-Length: 29
> Content-Type: application/x-www-form-urlencoded
>
* upload completely sent off: 29out of 29 bytes
< HTTP/1.1 200 OK
< Server: Apache-Coyote/1.1
< PROXY_SERVER_INFO: host=slcsbplatformapiserv3001.slc.paypal.com;threadId=384
< Paypal-Debug-Id: de62039a5a244
< SERVER_INFO: identitysecuretokenserv:v1.oauth2.token&CalThreadId=47502&TopLevelTxnStartTime=14b83d4e3f0&Host=slcsbidensectoken502.slc.paypal.com&pid=6295
< Date: Fri, 13 Feb 2015 16:45:42 GMT
< Content-Type: application/json
< Content-Length: 461
<
* Connection #0 to host api.sandbox.paypal.com left intact
* Closing connection #0
* SSLv3, TLS alert, Client hello (1):
{"scope":"https://uri.paypal.com/services/subscriptions https://api.paypal.com/v1/payments/.* https://api.paypal.com/v1/vault/credit-card https://uri.paypal.com/services/applications/webhooks https://uri.paypal.com/services/invoicing https://uri.paypal.com/payments/payouts https://api.paypal.com/v1/vault/credit-card/.*","access_token":"A0151dMXKPrBCWFFucj132Nvw87sS5NFntFDhhfF8la3Wsg","token_type":"Bearer","app_id":"APP-80W284485P519543T","expires_in":28800}
$
$ curl -v https://api.sandbox.paypal.com/v1/payments/payment \
> -H 'Content-Type: application/json' \
> -H 'Authorization: Bearer A0151dMXKPrBCWFFucj132Nvw87sS5NFntFDhhfF8la3Wsg' \
> -d '{
> "intent":"sale",
> "redirect_urls":{
> "return_url":"http://example.com/your_redirect_url.html",
> "cancel_url":"http://example.com/your_cancel_url.html"
> },
> "payer":{
> "payment_method":"paypal"
> },
> "transactions":[
> {
> "amount":{
> "total":"7.47",
> "currency":"USD"
> }
> }
> ]
> }'
* About to connect() to api.sandbox.paypal.com port 443 (#0)
* Trying 173.0.82.78... connected
* successfully set certificate verify locations:
* CAfile: none
CApath: /etc/ssl/certs
* SSLv3, TLS handshake, Client hello (1):
* SSLv3, TLS handshake, Server hello (2):
* SSLv3, TLS handshake, CERT (11):
* SSLv3, TLS handshake, Request CERT (13):
* SSLv3, TLS handshake, Server finished (14):
* SSLv3, TLS handshake, CERT (11):
* SSLv3, TLS handshake, Client key exchange (16):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSL connection using AES256-SHA
* Server certificate:
* subject: C=US; ST=California; L=San Jose; O=PayPal, Inc.; OU=PayPal Production; CN=api.sandbox.paypal.com
* start date: 2012-12-06 00:00:00 GMT
* expire date: 2016-12-06 23:59:59 GMT
* subjectAltName: api.sandbox.paypal.com matched
* issuer: C=US; O=VeriSign, Inc.; OU=VeriSign Trust Network; OU=Terms of use at https://www.verisign.com/rpa (c)10; CN=VeriSign Class 3 Secure Server CA - G3
* SSL certificate verify ok.
> POST /v1/payments/payment HTTP/1.1
> User-Agent: curl/7.22.0 (x86_64-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3
> Host: api.sandbox.paypal.com
> Accept: */*
> Content-Type: application/json
> Authorization: Bearer A0151dMXKPrBCWFFucj132Nvw87sS5NFntFDhhfF8la3Wsg
> Content-Length: 324
>
* upload completely sent off: 324out of 324 bytes
< HTTP/1.1 201 Created
< Server: Apache-Coyote/1.1
< PROXY_SERVER_INFO: host=slcsbplatformapiserv3001.slc.paypal.com;threadId=19925
< Paypal-Debug-Id: d2b2c56f78e41
< SERVER_INFO: paymentsplatformserv:v1.payments.payment&CalThreadId=196&TopLevelTxnStartTime=14b83d6cc6a&Host=slcsbpaymentsplatformserv3002.slc.paypal.com&pid=13409
< Content-Language: *
< Date: Fri, 13 Feb 2015 16:47:47 GMT
< Content-Type: application/json
< Content-Length: 740
<
* Connection #0 to host api.sandbox.paypal.com left intact
* Closing connection #0
* SSLv3, TLS alert, Client hello (1):
{"id":"PAY-3XB52861RA479681CKTPCVMY","
create_time":"2015-02-13T16:47:47Z",
"update_time":"2015-02-13T16:47:47Z",
"state":"created",
"intent":"sale",
"payer":{"payment_method":"paypal",
"payer_info":{"shipping_address":{}}},
"transactions":[{"amount":{"total":"7.47","currency":"USD","details": {"subtotal":"7.47"}},"related_resources":[]}],"links":[{"href":"https://api.sandbox.paypal.com/v1/payments/payment/PAY-3XB52861RA479681CKTPCVMY","rel":"self","method":"GET"},{"href":"https://www.sandbox.paypal.com/cgi-bin/webscr?cmd=_express-checkout&token=EC-39015200YL315920D","rel":"approval_url","method":"REDIRECT"},{"href":"https://api.sandbox.paypal.com/v1/payments/payment/PAY-3XB52861RA479681CKTPCVMY/execute","rel":"execute","method":"POST"}]}
"payment_method":"paypal"
This means the user (your customer) must (these are the missing steps in above):
be redirected to Paypal from your application to the approval_url returned in the response (their response to your last curl call).
the user will/must "approve" your request
user will be sent back to your site/application to the url you set in return_url
you'll need to execute the payment after that.
Reference: Accept a PayPal payment
This essentially maps to "Express Checkout" in the Classic API.
Hth..

Paypal was working with signature, now requires client certificate

I am integrating PayPal Express Checkout in the Sandbox using SOAP XML. SetExpressCheckout was working properly using a signature for credentials on 9/18/2013. I made no changes to my code or to the web server. I did begin work on Callback using NVP, since no SOAP version of Callback is available. The next day, SetExpressCheckout stopped working. I now get the following error: "80072f0c A certificate is required to complete client authentication" when trying to post to https://api-3t.sandbox.paypal.com/2.0/
Question 1: Could trying to use NVP Callback have caused PayPal's API server to now require a client certificate rather that a signature?
Question 2: Is there some other explanation for this change in behavior?
Question 3: Should I remove the signature from my sandbox account and request an API certificate instead? (Despite PayPal's recommendation that signatures be used rather than certificates.)
Note: I have tried using my own sandbox signature as well as the generic, "always works", sandbox signature. I have also tried posting to both api-3t.sandbox.paypal.com/2.0/ and api.sandbox.paypal.com/2.0/ (without -3t). None of these efforts eliminated the error.
Thanks, Chris H
are you still seeing this issue?
I am unable to reproduce it even using the IP you got back from nslookup.
Here my test with 23.51.43.42. I'm having the same positive result with 23.50.75.42
curl \
-H "Host: api-3t.sandbox.paypal.com" \
-d "USER=guus_1192700083_biz_api1.paypal.com&PWD=XXXXXXXXXX&SIGNATURE=XXXXXXXXXX&VERSION=108&METHOD=SetExpressCheckout&RETURNURL=http://www.paypal.com&CANCELURL=http://www.paypal.com&AMT=0.01&PAYMENTACTION=Authorization" \
https://23.51.43.42/nvp -kv
* About to connect() to 23.51.43.42 port 443 (#0)
* Trying 23.51.43.42...
* 0x8001f188 is at send pipe head!
* STATE: CONNECT => WAITCONNECT handle 0x80057568; line 1032 (connection #0)
* Connected to 23.51.43.42 (23.51.43.42) port 443 (#0)
* successfully set certificate verify locations:
* CAfile: /usr/ssl/certs/ca-bundle.crt
CApath: none
* SSLv3, TLS handshake, Client hello (1):
* STATE: WAITCONNECT => PROTOCONNECT handle 0x80057568; line 1145 (connection #0)
* SSLv3, TLS handshake, Server hello (2):
* SSLv3, TLS handshake, CERT (11):
* SSLv3, TLS handshake, Request CERT (13):
* SSLv3, TLS handshake, Server finished (14):
* SSLv3, TLS handshake, CERT (11):
* SSLv3, TLS handshake, Client key exchange (16):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSL connection using RC4-SHA
* Server certificate:
* subject: C=US; ST=CALIFORNIA; L=San Jose; O=PayPal, Inc.; OU=Partner Support; CN=api-3t.sandbox.paypal.com
* start date: 2013-08-20 00:00:00 GMT
* expire date: 2015-08-21 23:59:59 GMT
* issuer: C=US; O=VeriSign, Inc.; OU=VeriSign Trust Network; OU=Terms of use at https://www.verisign.com/rpa (c)10; CN=VeriSign Class 3 Secure Server CA - G3
* SSL certificate verify ok.
* STATE: PROTOCONNECT => DO handle 0x80057568; line 1164 (connection #0)
> POST /nvp HTTP/1.1
> User-Agent: curl/7.29.0
> Accept: */*
> Host: api-3t.sandbox.paypal.com
> Content-Length: 261
> Content-Type: application/x-www-form-urlencoded
>
* upload completely sent off: 261 out of 261 bytes
* STATE: DO => DO_DONE handle 0x80057568; line 1236 (connection #0)
* STATE: DO_DONE => WAITPERFORM handle 0x80057568; line 1352 (connection #0)
* STATE: WAITPERFORM => PERFORM handle 0x80057568; line 1363 (connection #0)
* HTTP 1.1 or later with persistent connection, pipelining supported
< HTTP/1.1 200 OK
< Server: Apache
< Content-Length: 133
< Content-Type: text/plain; charset=utf-8
< DC: origin2-api-3t.sandbox.paypal.com
< Date: Thu, 03 Oct 2013 20:07:10 GMT
< Connection: keep-alive
< Set-Cookie: DC=origin2-api-3t.sandbox.paypal.com; secure
<
* STATE: PERFORM => DONE handle 0x80057568; line 1533 (connection #0)
* Connection #0 to host 23.51.43.42 left intact
TOKEN=EC%2d03T72513NN7526924&TIMESTAMP=2013%2d10%2d03T20%3a07%3a10Z&CORRELATIONID=4776c1624af4e&ACK=Success&VERSION=108&BUILD=7920936