Post by Stinger23 » Thu Sep 22, 2022 2:06 pm

I've been running PayPal Commerce Platform on OC 3.0.3.1 for about a year and prior to that I've used older version of Paypal checkout. PayPal Commerce Platform added 3D Secure and ever since then, one thing that's always caused issues is there is a high rate of cards being declined. I'd estimate 25% of the customers get declined at least once before either changing cards or calling their bank and getting the fraud flag removed so the payment will clear. I know they are false declines because after the customer's failed multiple times, I've got their card/checkout info from them over the phone and tried to checkout for them using this info in order to avoid any typos and such and the cards still won't go through. However, if I run them using the Paypal Here app on my phone, the previously denied card will go through 95% of the time. When I asked Paypal about this, they said 3D Secure isn't used with Paypal Here which points back to my 3D Secure settings needing adjustment.

Initially I had all of the 3D secure scenarios set to their recommended accept/decline settings and there was an extremely high rate of declines, so high that it was rare for a payment to actually go through. To "fix" that I tried researching each scenario to try to understand it (with minimal success) so I finally just changed them all to "accept" even when the recommended selection was "decline". This is what got me to the current 75% success rate.

Obviously it's still frustrating to have 25% of my customers encounter "payment denied" messages when trying to checkout and it's certainly cost me some sales (not everyone comes back to try again). So I'd like to try to get the 3D Secure settings fixed so payments are only denied when they should be (wrong info entered, lack of funds, etc.) and not because it's falsely flagged as fraudulent by the bank.

Does anyone have any insight into these settings, what works well for you, which one is most likely to trigger a fraud flag, etc.? Here are the options that can be set to Accept or Decline and their recommended settings (which did not work for me at all):

Failed authentication. Decline (recommended)
Rejected authentication. Decline (recommended)
Attempted authentication. Accept (recommended)
Unable to complete authentication. Decline (recommended)
Challenge required for authentication. Decline (recommended)
Card type and issuing bank are not ready to complete a 3D Secure authentication. Accept (recommended)
System is unavailable at the time of the request. Decline (recommended)
System has bypassed authentication. Accept (recommended)

As stated, when I changed all of them to "Accept", it improved the ability to get payments cleared significantly but still has a much higher false decline rate than is acceptable.

Any insight would be greatly appreciated, thanks.

Newbie

Posts

Joined
Tue Jan 29, 2019 5:35 am

Post by ADD Creative » Thu Sep 22, 2022 6:42 pm

Make sure you are using the latest version on the extension from the marketplace.

You could try switching on the extension's debug log and look for the EnrollmentStatus and Authentication_Status results. This may give you a clue as to which one is failing.
https://developer.paypal.com/docs/check ... mentstatus

If you don't always want 3D Secure for every transaction, you could try adjusting the contingencies from 3D_SECURE to SCA_WHEN_REQUIRED.
https://developer.paypal.com/docs/check ... ecure/sdk/

www.add-creative.co.uk


Expert Member

Posts

Joined
Sat Jan 14, 2012 1:02 am
Location - United Kingdom

Post by Stinger23 » Fri Sep 23, 2022 1:10 am

Thanks. I've got debugging turned on but I'm not finding any hits when searching for any of the status names when viewing the log from System > Maintenance > Error Logs. Is the Paypal error log saved/viewed somewhere else?

The error log is filled with thousands of instances of the same errors which I don't understand (I'm not a developer) but I don't see anything that seems to be related to Paypal transactions (no hits when searching for Paypal or PP or 3D or secure or EnrollmentStatus or anything else I can think of).

These are the errors that seem to be repeated hundreds of times daily:
PHP Warning: Division by zero in /srv/xxxxxxx_prod/htdocs/store/catalog/controller/product/category.php on line 332
PHP Warning: A non-numeric value encountered in /srv/xxxxxxx_prod/htdocs/store/catalog/controller/product/category.php on line 346
PHP Warning: A non-numeric value encountered in /srv/xxxxxxx_prod/htdocs/store/catalog/controller/product/category.php on line 157
PHP Warning: A non-numeric value encountered in /srv/xxxxxxx_prod/htdocs/store/catalog/controller/product/category.php on line 332
PHP Notice: A non well formed numeric value encountered in /srv/xxxxxxx_prod/htdocs/store/catalog/controller/product/category.php on line 342
PHP Notice: A non well formed numeric value encountered in /srv/xxxxxxx_prod/htdocs/store/catalog/controller/product/category.php on line 157
PHP Notice: A non well formed numeric value encountered in /srv/xxxxxxx_prod/htdocs/store/system/library/pagination.php on line 94
PHP Notice: A non well formed numeric value encountered in /srv/xxxxxxx_prod/htdocs/store/catalog/controller/product/category.php on line 332

SCA when required looks promising. I'll dig into that.

Newbie

Posts

Joined
Tue Jan 29, 2019 5:35 am

Post by ADD Creative » Fri Sep 23, 2022 5:00 pm

The PayPal debug log is paypal.log in your logs folder.

The "A non well formed numeric value encountered" is probably this issue.
https://github.com/opencart/opencart/pull/8688

The "Division by zero" warning is probably due to a bad limit parameter in a category URL. Most likely caused by a bot. Looking in your web access logs at the same time of the error may give you more information.

www.add-creative.co.uk


Expert Member

Posts

Joined
Sat Jan 14, 2012 1:02 am
Location - United Kingdom

Post by Stinger23 » Sat Sep 24, 2022 2:41 pm

Thanks for the info about the other errors. I'll look into those after I resolve this payment issue.

One thing I forgot to mention is that I suspect having all of the Scenarios set to "Accept" may be making this site look fraudulent as there are a lot of cases where the customer payment is denied, they call the bank and are told their automated fraud alert system marked the transaction as possible fraud and shut it down. This is another reason why I'm hoping to figure out how to configure the scenarios correctly.

There are thousands of transactions to dig through so I didn't look at every one. I just searched for pertinent keywords and then looked at a few instances of each for trends.

So it appears an Enrollment_Status of "U" (System is unavailable at the time of the request) will not allow an order to go through as when this happens, it doesn't pass any identifying information that would allow me to link it to a particular order (order #, dollar amount, etc.). The only identifier I have is date/time and I don't ever see an order that matches that info. There are also Enrollment_Status of "U" instances where there are multiple attempts a minute or two apart (which matches the behavior I see in Admin when an order is denied...the customer keeps trying to get it to go through and Paypal keeps denying it).
Enrollment_Status of "N" will allow the order to go through.
Enrollment_Status of "B" doesn't exist in my log.

Authentication_Status":"N declines order initially sometimes but they often go through the second time even though the status is "N" both times. Sometimes they go through the first time.
Authentication_Status":"R allows the order to go through.
Authentication_Status":"A allows the order to go through.
Authentication_Status":"U allows the order to go through.
Authentication_Status":"C doesn't exist in my log.
Authentication_Status":"I doesn't exist in my log.
Authentication_Status":"D doesn't exist in my log.

So it appears Enrollment_Status of "U" (System is unavailable at the time of the request) and Authentication_Status of "N" (Failed authentication) are the ones that can result in declined payments. Both of these are scenarios where "Decline" is the recommended action, even though Authentication_Status of "N" (Failed authentication) will sometimes allow it to go through eventually.

Does this information mean I should change "System is unavailable at the time of the request" and "Failed authentication" to decline, or should I only change the first one since the second will sometimes go through eventually? Thanks again.

Newbie

Posts

Joined
Tue Jan 29, 2019 5:35 am

Post by ADD Creative » Sat Sep 24, 2022 7:24 pm

I would definitely set "Failed authentication" to decline, otherwise there would be not point in using 3D secure. For "System is unavailable at the time of the request", I guess this would depend on the location of you and your customers. If SCA is mandatory there then you probably want to decline. You may be best trying to speak to PayPal about it, if you see a lot of these.

www.add-creative.co.uk


Expert Member

Posts

Joined
Sat Jan 14, 2012 1:02 am
Location - United Kingdom

Post by Stinger23 » Sat Sep 24, 2022 11:38 pm

Thanks. I'm in the USA.

Based on my interactions with Paypal regarding other payment related issues, I'm guessing they would be of no assistance, and any assistance they did give would be different each time I contacted them. It took them over a year to explain why some card payments come through in Paypal as a random string of letters and numbers instead of the buyer's name. 15+ people on the developer support team all had different ideas, none of which turned out to be true. Then I finally lucked into talking to someone who had the answer and was surprised nobody else knew the cause of the issue.

I've actually contacted them about this in the past (at least trying to see why payments didn't go through) and in most cases they couldn't see the payment attempt at all because it was declined by the bank/card before it was in Paypal's hands. I'll certainly give them a try if nothing else resolves it though.

Newbie

Posts

Joined
Tue Jan 29, 2019 5:35 am

Post by Stinger23 » Tue Sep 27, 2022 2:32 am

I set the two mentioned to "decline" over the weekend so we'll see how it goes. I know the first order after the change was denied on the first attempt but went through the second time. It's possible that was the customer entering something wrong, or using a card that didn't have enough money available or something. Either way, I'll have to wait until there are a lot of new orders to look at so I can see if it's better or not. Thanks again.

Newbie

Posts

Joined
Tue Jan 29, 2019 5:35 am
Who is online

Users browsing this forum: No registered users and 40 guests