I'm currently developing an integration with PayPal's Payflow Pro Gateway. I'm sending a request to PayPal to get their "Secure Token" so that I can use that to do the real transaction. A sample I found on SO works via cURL, but the original HTML Form POST and RunScope tests I ran did not work.
Here is the cURL command:
curl https://pilot-payflowpro.paypal.com -kd "PARTNER=PayPal&VENDOR=*****&USER=*****&PWD=*****&TRXTYPE=A&AMT=40&CREATESECURETOKEN=Y&SECURETOKENID=*******&SILENTTRAN=TRUE"
Per the cURL documentation:
The -k option is:
"(SSL) This option explicitly allows curl to perform "insecure" SSL connections and transfers. All SSL connections are attempted to be made secure by using the CA certificate bundle installed by default. This makes all connections considered "insecure" fail unless -k, --insecure is used."
The -d option is:
"(HTTP) Sends the specified data in a POST request to the HTTP server, in the same way that a browser does when a user has filled in an HTML form and presses the submit button. This will cause curl to pass the data to the server using the content-type application/x-www-form-urlencoded. Compare to -F, --form."
-d, --data is the same as --data-ascii. To post data purely binary, you should instead use the --data-binary option. To URL-encode the value of a form field you may use --data-urlencode.
If any of these options is used more than once on the same command line, the data pieces specified will be merged together with a separating &-symbol. Thus, using '-d name=daniel -d skill=lousy' would generate a post chunk that looks like 'name=daniel&skill=lousy'.
If you start the data with the letter @, the rest should be a file name to read the data from, or - if you want curl to read the data from stdin. The contents of the file must already be URL-encoded. Multiple files can also be specified. Posting data from a file named 'foobar' would thus be done with --data @foobar. When --data is told to read from a file like that, carriage returns and newlines will be stripped out.
That works great and returns this response:
RESULT=0&SECURETOKEN=*****&SECURETOKENID=*****&RESPMSG=Approved
HTML Form POST
However, what I perceive to be the same request fails in the following HTML form POST:
<input type="hidden" name="TRXTYPE" value="A" />
<input type="hidden" name="SILENTTRAN" value="TRUE" />
<input type="hidden" name="AMT" value="40" />
<input type="hidden" name="CREATESECURETOKEN" value="Y" />
<input type="hidden" name="SECURETOKENID" value="*****" />
<input type="submit" value="Get Secure Token" />
That gives me "The connection was reset" in FireFox.
I also tried using jQuery to POST the data using $.ajax(), but I received a 200 response with no data in it.
Runscope
When I enter the above parameters into RunScope, I get:
RESULT=1&SECURETOKENID=*****&RESPMSG=User authentication failed
Which doesn't make any sense!
I was thinking that PayPal is either doing something with examining the user agent, or request headers, but I don't have any real idea. Can anyone shed some light on this behavior?
