How to simulate error scenarios in paypal smart buttons, and can I get error in JSON format in onError method in paypal smart button. I want issue and descriptopn of the error in onError method.
If you use the server-side front-end to call routes on your server, and in turn call the v2/checkout/orders API from your server, negative testing can be done with those underlying APIs: https://developer.paypal.com/docs/api-basics/sandbox/request-headers/
I'm not aware of ways to trigger errors with just a client-side integration.
If you want to test the error scenario then just pass that Invoice id which you used earlier for creating order request.
In on error function, you would not get any Json response but just a simple message showing a capture payment error.
Related
I have been successful with sending messages to Twilio via C# and Powershell but trying to use a Web Service call in Cherwell has me stumped.
I have setup the web service call.
I'm passing all the authentication tests because I can perform a lookup for the last 50 messages (which requires authentication) but when I try to call the Messages POST with To, From and Body I get a 400 error.
Unfortunately Cherwell only shows me the 400 error and not the return text from Twilio so I can't debug any further.
If anyone has done this can you please let me know how?
Also if you could recommend a way to put an HTTPS proxy between my Cherwell server and the Twilio endpoint to view the result values, that would help me out.
The key to this is building the message body as a single block of text that should be used as the body of the Web Service call.
Essentially, what you would have is a value that looks like
From=+17195550199&To=+17195550100&Body=Your text message here
I ran into this same issue while building this mApp to provide outgoing SMS capabilities: https://synapsesoftware.com/portfolio/twilio-mapp
I'm setting up a paypal payment option on the project i'm working on.
The authorization structure I use is an hybrid client + server REST.
The client generates the token as expected, after the user clicks "Pay now" on the paypal page.
Then the server receives its data (paymentID and payerID). So, i just ask for a bearer token (or use the one i had stored) and reach the
POST /payments/payment/{payment_id}/execute
endpoint, with no body at all.
Everything works fine, until the REST request, since it gives me a 500 error and no explanation at all of what I could have done wrong. Just in case some PayPal developers are reading this post, i'll also leave the debug id:
d78e7ca9e79b2
Another strange thing is that the
GET /payments/payment/{payment_id}/
request is working fine, also giving me as HATEOAS endpoint, the execute link, identical as the one I use. Did i miss something, in the execute call, so?
Were getting a lot of #INTERNAL_SERVICE_ERROR's through the rest PayPal API. To get more details about the error we have been going the PayPal Tech Support. We've been able to fix some of the issues but it is taking us a lot longer than we would like. I was wondering if there was an API call that I could make that would give me the full details of the error or DebugID?
I am not sure how you are currently consuming the API, but https://developer.paypal.com/webapps/developer/docs/api/ specs the error object which has the debug_id, the PayPal internal identifier used for correlation purposes. The error object has information link and error_details object which has the detailed reasons for the error
If you are using an sdk to consume, it is possible to get the debug_id in your logs: https://github.com/paypal/rest-api-sdk-nodejs#debugging and https://github.com/paypal/rest-api-sdk-python#create-payment show ways to do that in Python and Node.
I myself am looking for the same information. But it appears the debug ID is only so Paypal support can correlate the error to a transaction event. Technically there is no other information associated with the Debug ID.
See Receiving INTERNAL_SERVICE_ERROR REST API
I'm attempting to use SoapUI (5.0.0 beta) to test a RESTful web service which issues asynchronous responses to a supplied Callback URL.
So far, I am able to invoke the service and confirm the initial synchronous response received. I have also created a 'REST MockService' that issues an appropriate response to the callback received from the server, and I supply the endpoint for this as the Callback URL in the initial request.
What I am now struggling with is creating a test case that ties the two together such that I can 'expect' the asynchronous callback before proceeding to another step in my test case. I tried adding a 'Mock Response' Test Step to my test case following the initial request. However, this just yields an unhelpful 'Missing SOAP Operations to Mock in Project' error message. I took a brief look at the SoapUI source for this error message and discovered the method returning the error is first checking if I am using a WSDL interface. Why I would be doing so with a REST project is beyond me, but there you have it!
Appreciate any guidance on how to proceed!
Having logged a query on the SoapUI Community Board, it seems there is currently not a good mechanism for achieving this, but my query has prompted an enhancement request at least!
http://forum.soapui.org/viewtopic.php?f=5&t=23697
Would implementing openssl prevent users from changing the button values?
I've researched into encrypting buttons, from hosted to using openssl.
Using hosted buttons would provide security at the cost of flexibility although there are variables that you can override, but still you cant override the important ones.
would using and implementing openssl on my webserver prevent users from changing a non-hosted paypal button ?
or would it just be better to fall back to a hosted button and use/validate using IPN?
My answer is non–PayPal specific (applies to any kind of HTTP form input), but the short answer is no. Even SSL cannot prevent the browser from modifying the form values that it receives.
A user could use a bookmarklet to execute a JavaScript program of her choice on your page after it has loaded, which has the ability to change form values. Because SSL only protects the transport between the browser and the server, not after the page has been processed by the browser, it makes no difference at all whether you use it.
This could be automated with Greasemonkey, which is the same idea, except makes it even easier for users to install other people’s JavaScript programs to run on your web page. As above, using SSL does not affect this at all, because it is all execute client side, which you, as the server, have no control over.
As you alluded to, using encrypted PayPal buttons would solve the problem, as any modification of the button parameters would invalidate the checksum, and PayPal would not accept the item.
The best solution would be using Express Checkout. This allows you a great deal more flexibility than standard buttons can ever offer you.
If you're thinking if doing IPN, you're probably capable enough to integrate Express Checkout. All it really is, is 1 API call, followed by a redirect to PayPal, and a minimum of 1 more API call to finalize the payment.
A typical flow would look as follows:
Call the SetExpressCheckout API. If you're new to this, it's made dead-easy with PayPal's NVP API interface. You can just send the data as a GET NVP string to https://api-3t.paypal.com/nvp and get a response back in the same format.
Take the token from the response, and redirect to https://www.paypal.com/cgi-bin/webscr?cmd=_express-checkout&token=XXXXXXX (https://www.sandbox.paypal.com/cgi-bin/webscr?cmd=_express-checkout&token=XXXXXXX for Sandbox testing)
As soon as the buyer is returned, PayPal will append a PAYERID to your RETURNURL. If you can't find it, call the GetExpressCheckoutDetails API and supply your token to retrieve it.
With the PAYERID and TOKEN, call DoExpressCheckoutPayment to finalize the payment.
To get started with this, I'd suggest taking a looking at the PHP NVP SDK they offer at https://www.x.com/community/ppx/sdks#NVP