Can't fix Paypal "invalid_client" authentication error - paypal

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

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!

my server call v2/checkout/orders/ paypal sandbox return 404 Not Found

1: i used ios client create a order, get response as below
CurrencyCode: USD
Amount: 21.47
Short Description: Hipster clothing
Intent: sale
Processable: Already processed
Display: $21.47
Confirmation: {
client = {
environment = sandbox;
"paypal_sdk_version" = "2.18.1";
platform = iOS;
"product_name" = "PayPal iOS SDK";
};
response = {
"create_time" = "2019-12-16T12:12:48Z";
id = "PAYID-LX3XJQI4U759055JE198303J";
intent = sale;
state = approved;
};
"response_type" = payment;
}
Details: Subtotal: 12.98, Shipping: 5.99, Tax: 2.5
Shipping Address: (null)
Invoice Number: (null)
Custom: (null)
Soft Descriptor: (null)
Payee email: (null)
BN code: (null)
Item: '{1|Old jeans with holes|4.99|USD|Hip-00037}'
Item: '{1|Free rainbow patch|0.00|USD|Hip-00066}'
Item: '{1|Long-sleeve plaid shirt (mustache not included)|7.99|USD|Hip-00291}'
2: i can see transaction in https://developer.paypal.com/developer/notifications/
sb-g8ehg personal example
Receipt for Your Payment to Doe John
16 De[Removed. Phone #s not permitted]/td>
3: my server side want to get payment details , but 404
curl -v -X GET https://api.sandbox.paypal.com/v2/checkout/orders/PAYID-LX3XJQI4U759055JE198303J -H "Content-Type: application/json" -H "Authorization: Bearer A21AAHMxaNfgH67r9uGcKMtCHHMo-VDQHf4WGBEZIbzEtBo7_bSMXArvTYGEUub_gT3s2_XRCJJNbgdXTd9mmZiANBs2URVUg"
Note: Unnecessary use of -X or --request, GET is already inferred.
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, 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 / AES256-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: Aug 21 00:00:00 2018 GMT
expire date: Aug 20 12:00:00 2020 GMT
subjectAltName: host "api.sandbox.paypal.com" matched cert's "api.sandbox.paypal.com"
issuer: C=US; O=DigiCert Inc; CN=DigiCert Global CA G2
SSL certificate verify ok.
GET /v2/checkout/orders/PAYID-LX3XJQI4U759055JE198303J HTTP/1.1
Host: api.sandbox.paypal.com
User-Agent: curl/7.54.0
Accept: /
Content-Type: application/json
Authorization: Bearer A21AAHMxaNfgH67r9uGcKMtCHHMo-VDQHf4WGBEZIbzEtBo7_bSMXArvTYGEUub_gT3s2_XRCJJNbgdXTd9mmZiANBs2URVUg
>
< HTTP/1.1 404 Not Found
< Cache-Control: max-age=0, no-cache, no-store, must-revalidate
< Content-Length: 385
< Content-Type: application/json
< Date: Mon, 16 De[Removed. Phone #s not permitted]GMT
< Paypal-Debug-Id: d59bbbad78a81
<
Connection #0 to host api.sandbox.paypal.com left intact
{"name":"RESOURCE_NOT_FOUND","details":[{"issue":"INVALID_RESOURCE_ID","description":"Specified resource ID does not exist. Please check the resource ID and try again."}],"message":"The specified resource does not exist.","debug_id":"d59bbbad78a81","links":
It does not appear the SDK you are using implements v2/checkout/orders, and so when you request that PAYID it is 404 Not Found
Perhaps that SDK implements v1/payments or v2/payments instead

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 REST API: Requesting oauth token returns 500

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).