Hello Paypal experience experts,
Since about 5 months I'm trying to implementate version /v2 of the Paypal payment SDK.
I am looking for examples of what you should tell a customer what to do when receiving an error code in the Paypal payment response status code (HTTP?), other than 201.
I'm using the Paypal javascript SDK and PHP SDK with CreateOrder.php and CaptureOrder.php.
A basic test in the sandbox does function okay.
In PHP I will use a self created object from the Paypal response for easier error handling on the client side.
The only example which Paypal gives on their site is about code 422 'Instrument Declined'.
However Paypal also shows a number of other status codes, like 200, 202, 204, 4xx.
To be able to complete my error handling script I would like to have some examples of what the customer should do if any of the other error codes occur.
I would have expected that Paypal would have given those examples, but they seem not to exist (Paypal assumes they will not occur (?) ).
(There are other questions on this forum that look similar, but they are not about /v2)
Can somebody please help me with those examples?
Thank you in advance.
Martin
The best error-handling example for a server-based integration is at https://developer.paypal.com/demo/checkout/#/pattern/server
This shows how to restart with client-side JS in the case of the recoverable instrument declined. For all other cases, it simply shows the error message details returned. If you want to show a different message, you can customize it to your needs, but it is not necessary. The important thing is that in the case of errors you do still return some details from the backend to the frontend that your frontend knows what to do with, which is particularly important for the case of INSTRUMENT_DECLINED.
Other possible error types are documented toward the end of each API reference, for the case of the Orders API that can be found here.
Related
My question is simple yet I can't find any SO posts or PayPal documentation to answer it.
In the event of a PayPal user having some error being redirected after completing their checkout (internet goes out, browser crashes, they close their browser before the redirect goes through, random networking issues, etc.) How are we suppose to handle that?
I thought using the following REST API
GET /v1/payments/payment/<Payment-Id>
Would solve my problem but since the state returned from this request does not change from created to approved until the funds have been executed it is useless. In the case of having some redirect error you will not have been able to execute the funds and thus it will simply be in the created state still which does not help you.
Additionally I thought maybe PayPals IPN system used for CLASSIC API would be the answer to my problem but again it fails. The IPN system does not contain relevant information such as transaction ID which is needed to link the two systems together.
Is there no way to do automated error handling using the REST API?
Here we have long list of paypal errors
This list is asolutely unusable. For some errors "Short Message" should be shown to the user, for some errors "Long Message". Part of errors should be described to users in some cases we have to redirect user to Paypal. Can anybody suggest php library to process all these errors?
I don't think any such library exists at this time (and yes, some Paypal errors leave much to be desired). The closest I could find was this JSON Object, but it doesn't improve on the messages, only rehashes them. Maybe consider creating one and putting it in GitHub for public use?
After paypal updated their interface (sandbox.paypal.com for example is not working, now you have to go to developer.paypal.com) many of the things are not working: 2 of them are particularly frustrating and I was hoping someone here knew how to get around them:
Am I the only one whose sandbox customer test accounts are not able to make purchases? The transaction page says they are not available.
IPN validation is not letting me send a https request. When I do it says there is something wrong with the server name. Yesterday however before the update I could get verified status. If I dont put https, now my handler gives me an invalid responde status, code: 400. What does it mean?
To fix the HTTP 400 error, follow the instructions in https://www.x.com/content/bulletin-ipn-and-pdt-scripts-and-http-1-1 and update your code to pass "Host" information. Ideally, things should work with just the recommended changes from the above link. Apparently, thats not the case. Here is a fix from one of the PayPal MTS person - PalPAL sandbox IPN processor rejecting all messages?
Remove the "cmd=notify-validate" option from the validation URL. I tried this and it worked. Though it doesn't return the right string, atleast it doesnt break with the 400 error.
While we wait for a fix from Paypal, I wonder how a company like PayPal can cause such a huge blunder and not post anything on their status page - https://www.x.com/developers/paypal/documentation-tools/site-status/pp-cri. It just makes you think that even smaller companies can do a better job than companies like PayPal.
For the code:400 issue, you have to update the post to version 1.1. That information is located here.
https://www.x.com/content/bulletin-ipn-and-pdt-scripts-and-http-1-1 in this bulletin.
However, as I posted before the asp.net example uses a call, that does not exist, so I was only able to get mine partly working. After fixing this, the servers appear to be rejecting calls to https, or the cert they have installed is invalid.
Action Required before February 1, 2013
Merchants need to update their IPN and/or PDT scripts to use HTTP 1.1, and include the “Host” header in the IPN postback script. In addition to this bulletin, these merchants will be notified via a direct email.
Alright, seems to be fixed!
If you are having trouble logging in, like suggested above, clear cache and cookies and try again.
Regarding the error 400, seems to have been solved by paypal!
we are dealing with heavy chargebacks and refunds. But I am unable to identify how can I get the details of chargebacks and refunds. We have published our game through third party so they own the Company Account for transactions. We have asked them, but apparently they don't have anything to help us out. I have used Graph API to log the transaction details and I have also used the debug tool to find out the reason or details of chargebacks and refunds. but even our refunds does not have any reason attached with it. Please help me out of this. I have done alot of Google on this but i am unable to find out what I need to know
Regards.
All you will actually get is a “Refund Reason Code” – which of these there are, and how to access them, is described here:
https://developers.facebook.com/docs/payments/disputes/#refundcb_tracking
Edit:
It does not look like you can look up the refund reason code via the API – but Facebook will send it to you, via a ping to your callback URL:
“If the order has been refunded by Facebook, we will ping your callback with a payments_status_update for the order in questions with a status of refunded. In addition, there will be an additional field returned called refund_reason_code with one of the following values: […]”
So you will have to react to that and evaluate the refund reason code (save it to your database, …) in this callback.
I am creating an english and french website that will be using paypal for payment processing.
I have all of the PayPal API working properly, and currently I am just outputting any error messages to the user (L_LONGMESSAGEX). However this is always english, is there a way to output the error messages as french?
I saw a LOCALECODE parameter but that seems to be something else.
Or am I going to have to setup my own lookup table based off the error codes?
No. This is not possible.
The PayPal API error messages are intended for your use only; you're supposed to properly handle these exceptions within your own application, and output a more meaningful message to the buyer.
(For example; "L_LONGMESSAGE0=This transaction has already been approved" means nothing to your buyers. Yet "This transaction has been processed previously. Did you order twice? Give our support team a call if you have any questions regarding your order!" is a lot clearer.)