Zen Cart v1.5.5f PayPal Express Checkout issues

[madshaun1984]

Yeah, since the payment amount is 0, it appears the software protects itself from trying to submit a payment amount (includes/modules/payment/paypalwpp.php:

if (strval($optionsST['PAYMENTREQUEST_0_ITEMAMT']) <= 0) {

So, couple of options. Guess could set paypal to authorize instead of capture, then after a test payment is received, could cancel the purchase instead of refund it.

Just attempted that, wont even open the paypal window now...

10423 Transaction refused because of an invalid argument. See additional error messages for details. - This transaction cannot be completed with PaymentAction of Authorization.

Going to increase the price to an item of £1... However, have a feeling this will fail too as the error was originally found when an actual customer tried to purchase an item for £71.10...

[madshaun1984]

Update: Setting Authorize instead of Final Sale fails with same blank page / error code (10486).

This was for an item set at £1.00 inc: VAT £0.8333 pre:VAT.

I have also removed the API signiture from Paypal, and created / updated the modules config with new API Access details.

[madshaun1984]

Ok... gone back to the drawing board and have switched to sandbox again.

Purchases go through fine while in sandbox, so this must be being declined by the bank... for some reason. How would I find out / what would the most likely cause be?

Also, how do I fix the "blank" page issue, as that's really not useful...

I've checked the includes/modules/paypal/paypalwpp.php file has the extra string to catch the 10486 error as recommended elsewhere, but its clearly not working...

Thanks,
Shaun

[mc12345678]

Can't recall the message seen way back when, but at one point if the "older" VAT module was installed without making some changes to modules such as PayPal, a purchase would not go through properly. All that said to ask, what version or method of including VAT is being used?

Also, there was a change applied to PayPal I think in 1.5.5f associated with decimal differences and I don't know if that is playing a factor in this issue or not.

Another question that was asked was if any other methods of using paypal express other than buy now have been attempted such as logging in after arriving at the shopping_cart, stepping through checkout (checkout_shipping, checkout_payment and selecting paypal, then checkout_confirmation) and what, if any issues were experienced?

Another question related to the testing process (understanding that other customers seemed to end up having issues as well) was if you had logged out/logged back in, cleared sesions/cache/cookies, etc...

Yes some of these are guesses and possibilities, but am trying to rule out other issues.

Speaking of which, since there was a message generated in one of the paypal debug logs where that log had not been fully shared, would suggest cleansing it like done with the others and posting it as it should show more of what is happening "internally" to maybe she'd some light on the issue.

Lastly (for now), do things work differently if instead of entering £1 as the gross price to back calculate what the "original" price was, what happens if instead a realistic net price is entered to then calculate a gross price that shows what the value of the product is after adding the Value Added Tax?

[madshaun1984]

Ok so big update today, I bit the bullet in the end last night and reached out to paypal....

They said that due to the "risk assessment"associated with my registering the site as a "Retail" business and set the subcategory to "Tobacco related", the paypal system automatically flags the site as a high risk. For this eeason all transactions for the site were being automatically declined.

They have escalated it to their internal "branding" team to set about lifting this bar on payments,but in the meantime have given me a workaround of editing the category of my store in my profile setting (so I set it as "other retail - Non durable goods).

After making this change and switching the api access strings back to the live environment. I then edited my test product back to 0.01p in price, added it to cart, used a discount code to remove shipping costs and then successfully ran through checkout / paypal login and purchase.

I was returned to the site correctly etc... and payment shows as successful in both buyer / merchant paypal accounts, plus the order was raised correctly in my zen cart admin pages.

So... what this leaves to resolve now is the mystery (I have no way to test this now as I dont have a 0 balance funding source available, is the failed redirect to paypal due to a 10486 error being seen (as it appears that this just doesn't work? Or coukd it be due to some paypal f$%#ery had effectively blacklisted my site?).

Anyone know if this is actually going to occur to customers that are legitimately declined due to insufficient funds? And if so, how would I fix it if the suggested fixes are already a part of the module included with zen cart v1.5.5f?

Thanks to all who have offered input so far!
Shaun

[mc12345678]

Remember that log I discussed? It would/should provide the path of how the error was "collected"/identified such that the path of a user's issue could be also considered and reviewed.

It would appear that in this situation that even though error 10486 was thrown with the suggestion to redirect back to PayPal that there would not be anything that PayPal would support because it was not a customer issue but instead a "store" issue. (yes I know a setting to identify the type of product.)

What I'm saying is that the process incorporated to address 10486 is expected to be related to a customer problem. That the error code for a store problem wasn't sufficiently handled doesn't mean that the customer related problem wouldn't be handled. This should be testible (the software right?) through the sandbox mode and offering some customer level of information that would result in throwing 10486...

Afterall your question relates to how the software works on the store side when PayPal returns an error resulting from the customer's information, not as relates to the store's setup/product.

The other part of that would have been what was the uri on the browser when the blank page was seen? I'm guessing it was a paypal address with '?cmd=_express-checkout&token=' in it.

[madshaun1984]

Ah ok, yeah just escalated this again with paypal as the uri was ended "checkout_process" and didnt have the token attached.

They seem to believe that this would of been the result (as you mentioned) an incorrectly handled error code on paypals side and not due to the customer.

They are going to monitor for declined payments / test the site to ensure it isn't an issue once the bars lifted etc... so I'll leave this here for a bit but stop worrying about it for now.

Thanks again for the support with this... seems paypal should be giving a different error for this type of devlined reason if you ask me, as that would of made the issue easily identifiable and rectifiable immediately rather than cost me 2 days of checking / double checking every little detail...

Oh well, live and learn right...

Shaun

[mc12345678]

Thanks again for the support with this... seems paypal should be giving a different error for this type of devlined reason if you ask me, as that would of made the issue easily identifiable and rectifiable immediately rather than cost me 2 days of checking / double checking every little detail...

Oh well, live and learn right...

Shaun

Yup.

Also identifies further that the sandbox isn't quite as completely the same as the live side as they claim. :)