I'm trying to handle error payment denied from Paypal after doCapture method.
https://developer.paypal.com/docs/api/sandbox/nt-classic/#test-api-error-handling-routines
You can force two types of API errors: those related to the transaction amount, and those not related to the amount.
To trigger an error condition on an amount-related field, specify a error code value as a number with two digits to the right of the decimal point. For example, specify a value of 107.55 to trigger the 10755 error.
To trigger errors on fields that are not amount related, specify the error code in whole. For example, use a value of 10539 to trigger a "payment declined" error.
How to set the amount to trigger error ‘payment declined’ in magento 2
Any advice.
Thanks.
Documentation: Negative testing for PayPal's classic APIs
Related
How do I create multiple authorizations for an order?
According to the docs:
An order is valid for 29 days. During this period, you can request from one to ten or more authorizations to ensure the availability of funds. By default, you can make up to ten basic authorizations for each order. https://developer.paypal.com/docs/integration/direct/payments/orders/#overview
I tried creating an order with intent=authorize and then post with
https://api.paypal.com/v2/checkout/orders/orderId/authorize
First it succeeded, yet when I want to create another authorization, it gave me error:
issue":"ORDER_ALREADY_AUTHORIZED","description":"Order already authorized.If 'intent=AUTHORIZE' only one authorization per order is allowed." "debug_id":"47084737aefa3"
So I canceled the original authorization and then tried to create a new one, still got the same error.
Then I changed intent=capture, it gave me
"name":"UNPROCESSABLE_ENTITY","details":[{"issue":"ACTION_DOES_NOT_MATCH_INTENT","description":"Order was created with an intent to 'CAPTURE'. Please use v2/checkout/orders/order_id/capture to complete the transaction or alternately Create an order with an intent of 'AUTHORIZE'."
"message":"The requested action could not be performed, semantically incorrect, or failed business validation.","debug_id":"8c381672a8f1e"
Any help would be much appreciated!!!
The documentation you linked to is for v1/payments/orders, which are deprecated and very different in function and purpose from v2/checkout/orders.
v2/checkout/orders can only be captured a single time. An intervening authorization step is optional, if you need it.
I was helping a customer figure out an issue and creating test invoices in the sandbox.
After the 4th one I started getting this error:
{
"name": "BUSINESS_ERROR",
"message": "Number is too long.",
"information_link":
"https://developer.paypal.com/docs/api/invoicing/#errors",
"debug_id": "2ca1d32e1fed3"
}
What number is too long? I've tried looking through all the info and nothing appears too long our out of spec.
Hopefully somoene at Paypal can use the debug ID to track this. This test program has worked without issue for months.
So, after dealing with PayPal support the number that is too long was the invoice number.
When I started my testing in the sandbox I always had PayPal auto-generate the invoice number. It gave something like:
INV2-UR7F-35N45-DGQZ-BYDE
So, after a few tests, the invoice number was incremented (by PayPal) and eventually reached:
INV2-UR7F-35N99-DGQZ-BYDE
Now, on one more call the invoice would be incremented to:
INV2-UR7F-35N100-DGQZ-BYDE
Which is 26 characters, and the maximum length for invoice number is 25.
The solution? I was told to use smaller invoice numbers. ;)
I feel this is a possible bug in the auto-incrementation of the PayPal Invoice, but I am posting this so when others run into this they know what to do.
What I did was in my sandbox account call the Create Invoice Draft API with an invoice number like "Test001" so that there will be plenty of increments left in the invoice number. After that call there should be no need to supply an invoice number, at least for a very long time.
For Every PaypPal interaction we Do:
1.SetExpressCheckoutReq
2.GetExpressCheckoutDetailsReq
3.DoExpressCheckOutPaymentReq
I do create a billing agreement first and only on scheduled/subsequent orders we use this billing agreement for reference transaction.
Our Issue is:
With a new PayPal account (testpaypal#abc.com) DoExpressCheckoutPaymentReq failed for CITY = SuttonsBay, with the address validation error “10736” (Shipping Address Invalid City State Postal Code) for a user (USER A). And this was corrected in the subsequent request as Suttons bay.
But the same PayPal account(testpaypal#abc.com ) used for the second time with a different user (USER B) on the site, DoExpressCheckoutPaymentReq call succeeds for the wrong CITY = SuttonsBay and allows us to complete the order.
It is to be noted that on all scheduled order of the user, we use the DoReferenceTransactionReq, which has strict validation and this fails every time, esp. for the second scenario described above.
I would like to know why there are inconsistencies in Shipping address validation for DoExpressCheckoutPayment. It is because of this difference that our scheduled orders fails (as described in scenario 2 that allows incorrect address)
Do we any way to have strict Validation in DoExpressChecOutPayment - which solves our purpose?
We have a few sites that use PayPal Express (via SOAP). On all but one, if the DoExpressCheckoutPayment returns the following message:
10413: "The totals of the cart item amounts do not match order amounts."
Then it is classed as an error, and the Ack field is 'Failure', and the Error.SeverityCode is 'Error'.
However, on one site (using a completely different PayPal account), the same error message returns 'SuccessWithWarning' as the Ack and 'Warning' for the Error.SeverityCode.
I can't find a setting that would control whether this error is a SuccessWithWarning or an Error. Does anyone know why I've receive different responses for the same error?
I am testing MIGS Virtual Payment Client on a test account. When I select payment, I am directed to the Payment Server page where I can choose between Visa and MasterCard. I have been given the following test data in the MIGS manual:
I use 123 as CSC value. However, the transaction always fail with
vpc_VerStatus=E
vpc_TxnResponseCode=2
vpc_Message=Declined //for Visa
vpc_Message=The+card+holder+was+not+authorised.+This+is+used+in+3-D+Secure+Authentication. //for MasterCard
By the way, if I select MasterCard, I am prompted "Please enter your OSID or the last 5 digits of your NAB ID" and a Credit Limit. I use OSID with value 123456 and Credit Limit 10000 respectively. (These are values I entered by myself as I was not given information what to input there).
I had a look at this Commonwealth bank and MIGS Virtual Payment Client error code but it does not solve my problem.
Any help why the transaction is being declined?
Okay, there's a handful of things here you need to understand/check out.
1. Ensure the transaction value ends in $xyz.00 or it will always decline
MIGS behaves differently in TEST and PROD. In TEST, MIGS uses the "cents" portion of your test transactions to determine what response code to return, NOT whether you have correctly provided the necessary data for the transaction. These cents values are as follows:
$ XXX.00 returns "0 Transaction approved"
$ XXX.10 returns "1 Transaction could not be processed"
$ XXX.05 returns "2 Transaction declined - contact issuing bank"
$ XXX.68 returns "3 No reply from Processing Host"
$ XXX.33 returns "4 Card has expired"
$ XXX.51 returns "5 Insufficient credit"
2. Disable 3-D Secure
It looks like you're also getting caught by 3DSECURE, also known as "Verified by Visa" and "Mastercard SecureCode". Call your acquirer/bank and ask them to disable this in TEST and Prod. Why? Invariably when this goes live, your customers will see a screen they are not expecting that asks for more information and then either pick up the phone and ask you to "fix it" or (even worse) leave your store thinking it's fraud.
Because 3-D secure has such low takeup, even most bank support staff don't know about it. Just today I had one of my clients call me about this "issue". One of their customers had called their card issuer to enquire as to what this "Verified by Visa" screen was. The bank (a major Australian bank) helpfully told them it was probably fraud and to not buy anything from that site.
3-D secure has such low penetration in Australia I'd suggest the only outcome of having it enabled is to reduce sales. Don't use it.