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
Related
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!
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
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?
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..
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).