How should I handle SUCCESSWITHWARNING when using classic Paypal api?
I searched web for this response but I can't find what it exactly mean and what should I do when I get SUCCESSWITHWARNING response from Paypal.
I know this is an old question, but I'd like to share our recent experience with the "SuccessWithWarning" response.
Here was the relevant parts of the paypal response:
[ACK] => SuccessWithWarning
[L_ERRORCODE0] => 10571
[L_SHORTMESSAGE0] => Transaction approved but with invalid CSC format.
[L_LONGMESSAGE0] => This transaction was approved. However, the Card Security Code provided had too few, too many, or invalid character types but, as per your account option settings, was not required in the approval process.
After looking at the long message, we decided that in this instance, it should be handled as a successful transaction.
In the paypal Fraud prevention documentation they give an example of when this might occur, https://developer.paypal.com/docs/classic/fmf/integration-guide/FMFProgramming/#nvp-example, eg: it's waiting for you to review it. They suggest that you do not discard these transactions, but capture them. Put your order in pending, but do NOT automatically ship them.
So, capture the short and long message, but review the message before shipping.
Related
Everything is good at sandbox environment, but something wrong in production.
First, i created a payment with enough information. It's still good.
Second, I redirect to apprvoved url for end user, user accepted payment.
Lastly, i make a request execute payment within payerId, but i received response error, it's return 400 and message name TRANSACTION_REFUSED.
Anyone help me!
Detail payment: here
Detail error: here
The payment attempt was rejected by PayPal. This error is normal behavior when a payment is declined.
Have the user use a different account or payment method.
Unrelated to the decline issue, you are using a deprecated v1/payments API, which should not be used for any new integrations. Here is how to change to a current v2/checkout/orders integration:
Make two routes on your server, one for 'Create Order' and one for 'Capture Order', documented here. These routes should return only JSON data (no HTML or text). The latter one should (on success) store the payment details in your database before it does the return (particularly purchase_units[0].payments.captures[0].id, the PayPal transaction ID)
Pair those two routes with the following approval flow: https://developer.paypal.com/demo/checkout/#/pattern/server
Sadly, PayPal's documentation is woefully inadequate.
What are the possible values for payment_status, and when do they occur?
I am aware of:
Completed - pretty self-explanatory
Pending - eCheque payment that hasn't gone through yet
And... that's it. That's all that's mentioned in the documentation.
But I need to know, what other values exist? What do you get if an eCheque is denied? What about when a client (fraudulently, -mutter mutter-) issues a chargeback against a payment (and rips you off for a few hundred quid -more muttering-), what does IPN send in these cases?
Ultimately I want to automate more of the scenarios that come up. For instance, if a Pending transaction arrives then I want to be able to reliably explain to the client that their eCheque is pending and they will be notified when it clears, and then proceed to notify them when it is indeed cleared (or denied).
Since I deal in virtual currency, I want to be able to debit a user's account automatically if they file a chargeback, but then credit them again if the chargeback is resolved and the funds returned to me.
And I really don't like how there might be other scenarios that I can't prepare for, simply because the documentation is shite.
Anyone got some hands-on experience, or are there any actual devs from PayPal who will honour this call?
I have the following flow with Paypal:
I create a payment with intent "order", and I redirect the user to Paypal's website.
Once the user returns, I execute the payment.
Then, I authorize the order.
At this point, I can still look up the payment or the order and I get expected result.
Finally, I capture the order.
After I capture the order, I can't lookup the payment with /v1/payments/payment/PAY-XYZ or retrieve the order with /v1/payments/orders/O-ABC. I get a 500 Internal Service Error.
Before you tell me to send debug id to Paypal because I stumbled upon their bug: I tried, but they are not responding. I had them on the phone, sent support requests, etc. I got no reply from them, so I have to turn to community.
After capture, I can still lookup a payment by listing payment resources. Since I store paypal's create time, I send a GET request that looks like:
/v1/payments/payment?start_time=2016-06-21T09:08:56Z&end_time=2016-06-21T09:08:58Z
Sure enough, I can get the payment object back, but that looks awfully hacky to me.
The reason why I need the entire payment object is because I need a definitive information about the status of the payment. E.g. I can stumble upon a network error when I send a capture request and I won't get capture ID, so I can't check what's going on. Or I can miss a webhook event (for any reason, e.g. bug in my code), and the payment can become refunded without me knowing, so it would be ver nice to be able to fetch a payment.
I noticed the REST API documentation here https://developer.paypal.com/docs/api/payments/#payment_get says that I should use that endpoint for incomplete payments, but I don't understand why I can't check the order, or why list payment resources works, but fetching a single payment doesn't.
Retrieving the payment used to work though, so I could look up related_resources of transactions of the response (like I can do now with listing all payments by date).
My question is: what is the recommended way to get the definitive information about a payment?
Also, if someone from Paypal is reading this, here are some debug_id's so you can perhaps look into it: 3ffa3007a7561 (result of https://api.sandbox.paypal.com/v1/payments/orders/O-3PA36862ST053572T) or 85576d66784cd (response from https://api.sandbox.paypal.com/v1/payments/payment/PAY-7N237030X85089344K5UQIKI)
This happens on both sandbox and live.
Thanks,
Dejan
I'm testing my PayPal's accounts with SandBox, I read that after PayPal answer I should send a post request with my transaction id, but I don´t understand why. When PayPal send's me request with GET, mi account show operation complete, so:
1.- Why I need send a post request with confirmation if PayPal already done the transaction?
2.- Why I need a Identity token if PayPal already done the transaction?
Thanks.
I've been thinking, after read many times the process, and the reasons to use PDT instead IPN, answered both questions:
1.- I need send a post request to PayPal to verify transaction is real and was made to me.
2.- I need a identity token, because that's the way to say to PayPal "Hey, it's really me, tell me if transaction is real and was made to me"
This avoids that malicious users send me false url request or repeated request (in that case PayPal should't tell me SUCCESS". So, at the time to know than transaction is real and was made to me, I can update my stock, for example
I noticed following details in paypal response
'PAYMENTINFO_0_PROTECTIONELIGIBILITY' => 'Eligible'
'PAYMENTINFO_0_PROTECTIONELIGIBILITYTYPE' => 'ItemNotReceivedEligible,UnauthorizedPaymentEligible
I found details about these in paypal documentation
ProtectionEligibility: the kind of seller protection in force for the transaction
ProtectionEligibilityType: the kind of seller protection in force for the transaction
I can't understand what this really means. What should I do in my integration?
There is no any problem with checkout but I can't understand what should I do when receive these information?
That info is simply provided so you know whether or not your transaction is covered by PayPal Seller Protection. In this case it is eligible for potential disputes where the buyer claims they didn't receive the item or if a unauthorized payment was made (ie. stolen credit card, phished PayPal account, etc.)
You might get a transaction where it's Ineligible, or maybe still eligible but only for ItemNotReceived. It all depends on the transaction and the variables involved.
So you don't really have to do anything when you receive that info other than decide how you want to treat the order. If the item was Ineligible, for example, you may simply decide to cancel the order and refund the payment.