PayPal RESTful API Payment Module

[lat9]

I just got this email from PayPal. I wonder if it's related to the issue we are seeing with the state being incorrect when it's sent to PayPal:

"We’ve spotted an API error that’s causing payment failures at checkout. Here's the error description:

"The INVALID_RESOURCE_ID error occurs when the information sent to PayPal's system is incomplete, incorrect, or formatted improperly. This typically happens when required details are missing or don't match what PayPal expects."

Fixing this issue will ensure your customers have an easy checkout experience while keeping your business running smoothly.

Here’s a step-by-step guide that will help you tackle this issue."

They link to this guide: https://developer.paypal.com/communi...=040225_v1_sms

EDIT: As a reminder, I am using the latest version 1.0.5 on ZC 1.5.8a, and the module is in AUTHORIZE ONLY mode since we need to verify all credit card AVS response before we decide to authorize the card due to fraud. Mentioning that Authorize Only setting in case it's related to the issue (since most customers may not be using that mode).

Interesting, but there's nothing to go on without details as to what information is "incomplete, Incorrect or formatted improperly".

[Jeff_Mash]

Interesting, but there's nothing to go on without details as to what information is "incomplete, Incorrect or formatted improperly".

I know, right! Not very helpful of them. I did want to include it here though in this thread because 1) we are seeing that pesky issue with "CA" being sent as the State to PayPal (even though it's fine in the ZenCart Orders table), and 2) Whatever is happening, it might be related to that email from PayPal since we have experienced no other issues like this with the old PayPald and Paypalwpp modules.

[JG64]

We are upgrading to the Paypal RESTful paypalr with Zencart v2.1.0 and ZCA Bootstrap-4 v3.7.5. We have setup live and sandbox API's through our Paypal Developer portal and set 'Accept Credit Card?' to 'true. The store is in sandbox environment. When we go to make a test purchase using a PayPal sandbox credit card. The following log file shows two errors. I'm hoping someone can shed some light on them. Thanks!

Log File: paypalr-c-84-******-20250218.log

***--> CreatePayPalOrderRequest, amount mismatch (138.73 vs. 138.72). No items or cost breakdown included in the submission to PayPal. Error amount:
{
"currency_code": "USD",
"value": "138.72",
"breakdown": {
"item_total": {
"currency_code": "USD",
"value": "119.88"
},
"shipping": {
"currency_code": "USD",
"value": "11.65"
},
"tax_total": {
"currency_code": "USD",
"value": "7.20"
}
}
}

The curlPost (v2/checkout/orders) request was unsuccessful.
{
"errNum": 422,
"errMsg": "An interface error (422) was returned from PayPal.",
"curlErrno": 0,
"name": "UNPROCESSABLE_ENTITY",
"message": "The requested action could not be performed, semantically incorrect, or failed business validation.",
"details": [
{
"issue": "PAYEE_NOT_ENABLED_FOR_CARD_PROCESSING",
"description": "Payee account is not setup to be able to process card payments. Please contact PayPal customer support."

[lat9]

The first informative part (not an error, per se) indicates that a penny-off rounding error occurred during the order's total calculation.

The second part indicates that the site's not enabled at PayPal to collect credit-card payments. You need to contact PayPal directly for that authorization.

[JG64]

lat,

Thank you very much for the reply!
Our live site is authorized to collect credit card payments. Is it possible we just missed something in the admin area, or does the new module require something to change on PayPal's end?

[lat9]

lat,

Thank you very much for the reply!
Our live site is authorized to collect credit card payments. Is it possible we just missed something in the admin area, or does the new module require something to change on PayPal's end?

It's possible that since this version of PayPal payments uses a different API that you'll need to register the API to collect credit-card payments via your PayPal management console.

[JG64]

lat9,

Thanks!
We've put in a ticket at PayPal support (misnomer)
Hopefully they offer some resolution.

[balihr]

Just installed this on 1.5.8a, php 7.4.33, OPC 2.5.4

We were looking for 3DS verification so I placed an order with a card that is enrolled and it just went straight to checkout_success. OK, small amount, I guess PayPal didn't see any flags so it allowed the transaction.
I then started to look for an option to force 3DS, but the option wasn't there so I looked in paypalr.php - I commented the if statement on lines 1262 and 1282, as well as the if statement in includes/modules/payment/paypal/PayPalRestful/Zc2Pp/CreatePayPalOrderRequest.php on line 456
I believe this is all there is related to SCA_ALWAYS.

I started checkout, it went to confirmation and then to paypal where I was requested to do the 3DS verification. I clicked the provided "cancel" button, it took me back to the website and to checkout_success page. My card was charged.
Tried again, got to 3DS verification, entered my bank app and clicked Decline in the app, the app warned me the transaction will be cancelled if I confirm, I confirmed and landed on checkout_success with my card charged.

No matter what I tried, even if 3DS fails, the order is still created and card is charged. Is this a bug or expected behavior? I would expect the transaction to fail if 3DS fails... Or am I missing something stupid here?

In debug logs, I have the following (happy to PM full log if needed):

CreatePayPalOrderRequest::__construct(card, ...) finished, request:
...
'payment_source' => 
        'attributes' => 
      array (
        'verification' => 
        array (
          'method' => 'SCA_ALWAYS',
        ),
      ),
    ),
  ),

2025-02-18 18:28:12: (checkout_process) ==> Start createOrder
TokenCache::get, using saved access-token; expires in 28843 seconds.
The curlPost (v2/checkout/orders) request was successful (201).
{
    "id": "38Y93193YUxxxxxxx",
    "status": "PAYER_ACTION_REQUIRED",
    "purchase_units": [
        {
            "reference_id": "default"
        }
    ],
    "links": [
        {
            "href": "https:\/\/api.paypal.com\/v2\/checkout\/orders\/38Y93193YUxxxxxxx",
            "rel": "self",
            "method": "GET"
        },
        {
            "href": "https:\/\/www.paypal.com\/webapps\/helios?action=verify&flow=3ds&cart_id=38Y93193YUxxxxxxx",
            "rel": "payer-action",
            "method": "GET"
        }
    ]
}
2025-02-18 18:28:13: (checkout_process) ==> End createOrder
2025-02-18 18:28:13: (checkout_process) before_process, sending the customer off to a 3DS link (https://www.paypal.com/webapps/helios?action=verify&flow=3ds&cart_id=38Y93193YUxxxxxxx).

2025-02-18 18:28:27: (index) ppr_webhook_main (3ds_return, live) starts.
{
    "op": "3ds_return",
    "error": "error",
    "error_description": "error",
    "liability_shift": "NO",
    "main_page": "index"
}

2025-02-18 18:28:28: (checkout_process) ==> Start captureOrder

[lat9]

SCA_ALWAYS was a means to test the SCA paths through the code during sandbox testing; it has no affect when running live transactions.

[balihr]

OK, so... If my understanding is correct, there's no 3DS with this module? I'm looking at the API docs and it looks like SCA_ALWAYS means 3DS is always triggered, but then irrelevant of the response, this module lets the transaction through?

Could you point me in the right direction as to where to place the code to check their 3DS response and either proceed or decline the transaction based on 3DS response?