I'd like to make test request for paypal payment with realex.
Request looks like:
curl -X POST \
https://test.realexpayments.com/epage-remote.cgi \
-H 'Cache-Control: no-cache' \
-H 'Content-Type: application/xml' \
-H 'Postman-Token: b83626b9-9472-25d6-cb36-6143a480bf69' \
-d '<?xml version="1.0" encoding="UTF-8"?><request type="payment-set" timestamp="20180222134621"><merchantid>realexsandbox</merchantid><account>internet</account><orderid>IgGjoyQSRXqRyIvG30S5zQ</orderid><amount currency="EUR">1001</amount><autosettle flag="1"/><sha1hash>1524dcf16adca3af772ff4d6a035dd3789d5a4e9</sha1hash><paymentmethod>paypal</paymentmethod><paymentmethoddetails><ReturnURL>https://www.example.com/success</ReturnURL><CancelURL>https://www.example.com/failure</CancelURL></paymentmethoddetails><sha1hash>2d630f0d401ee62c711db6ab37b79f2ad43f201e</sha1hash></request>'
Body looks fine, possibly endpoint https://test.realexpayments.com/epage-remote.cgi is not the right one, as I always get response:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<response timestamp="20180223104630">
<result>503</result>
<message>No request type specified</message>
</response>
Can anybody help me with that?
Thanks for your question. When testing PayPal please use the following endpoint:
https://api.sandbox.realexpayments.com/epage-remote.cgi
The test.realexpayments endpoint is just for quickly testing card payments when you don't have a Sandbox account.
Best,
Seán
Realex Payments
Related
I am new using PostMan; normally I use curl:
this one to get the JTW
curl -X POST -H "X-Requested-With: XMLHttpRequest" -H "Content-Type: application/json" -H "Cache-Control: no-cache" -d '{ "username": "peris","password": "3nRam0nD3L3s0l1v3s" }' "http://139.152.231.107:1133/canPeris/auth"
and this other one using the JTW obtained before
curl -X GET -H "Content-Type: application/json" -H "Authorization: Bearer eyJhbGciJIUzUxMiJ9.eyJzdWIiOiJsb3Blei5hbnRvbmlvODVAZ21haWwuY29tIiwiZXhwIjoxNTkwMDQ3NTg4LCJpYXQiOjE1Mh9.3vlQBgfA22ffJZqNic2lVSHiMR6YudlCFoldfwzdk-clz6_XyOvCVTrMihXtYBaJuPI515zTwAnaQBV_h4yquA" "http://139.152.231.107:1133/canPeris/api/v1/users/3/menus/vegans"
I am using this to generate the token
return io.jsonwebtoken.Jwts.builder()
.setClaims(claims)
.setSubject(subject)
.setIssuedAt(createdDate)
.setExpiration(expirationDate)
.signWith(SignatureAlgorithm.HS512, secret)
.compact();
but in the postMan Signature method I haven't found the HS512
I think this can solve your problem.
Goto to Auth tab and select Bearer Token:
Add your Token:
Add the header Content-Type: Application/json, if necessary:
Send your request.
If you planing automate the access token acquisition and use in another request, I recommend read about postman tests and variables: https://medium.com/#codebyjeff/using-postman-environment-variables-auth-tokens-ea9c4fe9d3d7
I try export and import nifi templates via nifi rest api; but when i tried to delete controller-services, connections or import a template i get the response message "The revision must be specified." with '400 bad request' status from nifi rest api. I didn't understand what i have to do.
This my request for delete a control-service,
request "/controller-services/{id}" (id is, The controller service id.)
curl -X DELETE \
http://localhost:8090/nifi-api/controller-services/015b1030-a099-13d3-812c-77772afcaeb0 \
-H 'cache-control: no-cache' \
-H 'content-type: application/x-www-form-urlencoded' \
and the response is "The revision must be specified."
status : "400 Bad Request"
Any idea please?
I finally got some answers about my mistake after reading this article
It seems you have to add two information to request url; version and clientId.
After make a call and get a component form nifi instance, it sends a version number inside a DTO to you as explained here
like this:
and finally i made a call like below and it worked:
curl -X DELETE \
'http://localhost:8090/nifi-api/controller-services/015b1030-a099-13d3-812c-77772afcaeb0?version=0&clientId=5ed15669-015d-1000-99cf-bc9c6f378085' \
-H 'cache-control: no-cache' \
-H 'content-type: application/x-www-form-urlencoded' \
Rundeck supports triggering jobs via their API. The API documentation is available under documentation.
We are using API version 13 which does not yet support application/json. Therefore i need to use the XML based request.
In my previous attempts, i always get the response:
<result error="true" apiversion="13">
<error code="api.error.job.options-invalid">
<message>Job options were not valid: Option 'container' is required. Option 'version' is required.
</message>
</error>
</result>
Since there is no example request provided, i am searching for an example payload to trigger the job.
As seen in the response i have to provide the parameters "container" and "version" since they are required.
My most recent request payload was:
<executeJob>
<argString>-container containerName -version 1234567</argString>
</executeJob>
I also tried different variations of this payload, every time with the same response.
This should help you, assuming you have a token to access Rundeck with authorization to run the job
curl -D - -X "POST" -H "Accept: application/json" \
-H "Content-Type: application/json" \
-H "X-Rundeck-Auth-Token: <TOKEN>" \
-d '{"argString":"-arg1 val1 -arg2 val2"}' \
http://<URL>/api/16/job/<JOB_ID>/executions
Trying to use the Google CardDAV API to get at user's address books under my account. I have successfully gathered the base info for the principal user (PROPFIND current-user-principal), and the Home Set and addressbook of the principal, as defined in the Google CardDAV API document. I have users within the principal account, and I want to get the addressbook of those users. The documentation, and what info I have managed to wring out of the RFCs, suggests that I might use:
curl --request PROPFIND \
--header "Content-Type: text/xml" \
--header "Depth: 1" \
--header "Authorization: Bearer ya29.wwAiN8Xex0IrvCJx5_zRgB1RdO5iFeH7cyYzpU_3aPRZIDi9Q5j1mSmzk9IqqcbwIWEnJijNPOqysOnDqTpt7Ie6Ef9b7WrBLVDCTuNKfhjA2m6m7w604CDm" \
--data-ascii "<?xml version=\"1.0\" encoding=\"utf-8\"?> \
<D:propfind xmlns:D=\"DAV:\"> \
<D:prop> \
<D:current-user-principal /> \
<D:principal-URL /> \
<D:resourcetype /> \
</D:prop> \
</D:propfind>" \
https://www.googleapis.com/carddav/v1/principals/<USER EMAIL>/lists/default
But that gives me:
<?xml version="1.0" encoding="UTF-8"?>
<errors xmlns="http://schemas.google.com/g/2005">
<error>
<domain>GData</domain>
<code>notFound</code>
<internalReason>Not Found</internalReason>
</error>
</errors>
Thoughts?
thanks,
Andy
The example call in the PayPal Invoicing API documentation is returning an error?
Request
curl -s --insecure -H "X-PAYPAL-SECURITY-USERID: caller_1312486258_biz_api1.gmail.com" -H "X-PAYPAL-SECURITY-PASSWORD: 1312486294" -H "X-PAYPAL-SECURITY-SIGNATURE: AbtI7HV1xB428VygBUcIhARzxch4AL65.T18CTeylixNNxDZUu0iO87e" -H "X-PAYPAL-REQUEST-DATA-FORMAT: JSON" -H "X-PAYPAL-RESPONSE-DATA-FORMAT: JSON" -H "X-PAYPAL-APPLICATION-ID:APP-80W284485P519543T" https://svcs.sandbox.paypal.com/Invoice/CreateAndSendInvoice -d {\"requestEnvelope\":{\"errorLanguage\":\"en_US\"},\"invoice\":{\"merchantEmail\":\"caller_1335455804_biz#x.com\",\"payerEmail\":\"sender_1335455648_per#x.com\",\"currencyCode\":\"USD\",\"paymentTerms\":\"DueOnReceipt\",\"itemList\":{\"item\":[{\"name\":\"BananaPlant\",\"quantity\":\"1\",\"unitPrice\":\"38.95\"},{\"name\":\"PeachTree\",\"quantity\":\"2\",\"unitPrice\":\"14.95\"}]}}}
Response
{"responseEnvelope":{"timestamp":"2013-08-22T23:58:47.340-07:00","ack":"Failure","correlationId":"4838886d6636b","build":"7236486"},"error":[{"errorId":"580001","domain":"PLATFORM","subdomain":"Application","severity":"Error","category":"Application","message":"Invalid request: {0}"}]}
Try wrapping the payload in the -d switch within "". Running the curl snippet with the -v switch as-is will show you that the payload gets truncated and hence the "Invalid request" error.
Also, you will see a "Invalid token" error when the merchantEmail in the request is not the same as the API caller. If you need to generate invoices on behalf of a third party (in which case the API caller and merchantEmail are naturally different), you must obtain third party permissions and attach a X-PAYPAL-AUTHORIZATION header to your request.