PayPal RESTful API Payment Module

lat9:

... and if it's successful, someone will issue a refund?
FWIW, I made it to PayPal's confirmation page. Does that count as a success?

lat9:

... and if it's successful, someone will issue a refund?

Yes, absolutely, me... but you don't have to go that far I get the error right after login. Worth nothing previous version 1.0.2 was working

lat9:

FWIW, I made it to PayPal's confirmation page. Does that count as a success?

You logged in to PP? Right after I login I get the go back error provided

Maybe it's just an issue with my own PP account I guess. I still can't

For the life of me, I cannot figure why this is happening. Can anyone else look at the details of their PayPal Wallet transactions to see if it is putting the wrong state in the address?

For example, I take an order through ZenCart that is shipping to Chicago, Illinois. Everything is correct on ZenCart.

But when I click on "Click for Additional Payment Handling Options" and then hit DETAILS, it shows the STATE as being "CA". Our business is in California.

See image:

This doesn't happen on every order (I don't think) but it's happening a lot. Enough to be concerned, because PayPal's Seller Protection only is valid if you ship to the address that is given to PayPal, and it's giving them this incorrect state.

1. Whenever this happens to us, the incorrect state is ALWAYS put as "CA."

Is there any file I can look at which would be pushing this value to PayPal so I can see if one of us hardcoded something that is causing this? I don't understand what would be causing "CA" to be given to PayPal under the DETAILS that is pushed to them.

When you view the order in PayPal's management-console, what shows for the order's shipping address?

lat9:

When you view the order in PayPal's management-console, what shows for the order's shipping address?

When I log into PayPal and pull up the order, it also has the incorrect state ("CA") which matches what the plugin shows me under "Click for Additional Payment Handling Options" --> Details.

So to recap: the state is correct in the ZenCart database (Orders --> Shipping State/BillingState). But it is NOT correct under the Plugin's transaction Details, nor is it correct when logging into PayPal to see the details. See attachments.

Jeff_Mash:

When I log into PayPal and pull up the order, it also has the incorrect state ("CA") which matches what the plugin shows me under "Click for Additional Payment Handling Options" --> Details.

So to recap: the state is correct in the ZenCart database (Orders --> Shipping State/BillingState). But it is NOT correct under the Plugin's transaction Details, nor is it correct when logging into PayPal to see the details. See attachments.

Hi Jeff,
I just wondered if you are still using the Restful module? Maybe its just a slight glitch on the admin side perhaps, but all else okay. Just curious as I have to give notice to my payment network if I go on to Restful instead.

HeathenMagic:

Hi Jeff,
I just wondered if you are still using the Restful module? Maybe its just a slight glitch on the admin side perhaps, but all else okay. Just curious as I have to give notice to my payment network if I go on to Restful instead.

Yes, I am still using it, because it's a great module. But I still have the problem of occassional transactions posted to PayPal with "CA" as the state, even though the actual state could be Illinois or something else.

Apparently no one seems to know WHY this is happening. I see no rhyme or reason to it. It doesn't happen on all orders, only some. Our configuration is set to AUTHORIZE ONLY, because we manually capture the final sale after we vet the customer for fraud. That is how we caught this error, because we noticed a lot of the posted PayPal addresses had the different state than the actual address on ZenCart.

Jeff_Mash:

Yes, I am still using it, because it's a great module. But I still have the problem of occassional transactions posted to PayPal with "CA" as the state, even though the actual state could be Illinois or something else.

Apparently no one seems to know WHY this is happening. I see no rhyme or reason to it. It doesn't happen on all orders, only some. Our configuration is set to AUTHORIZE ONLY, because we manually capture the final sale after we vet the customer for fraud. That is how we caught this error, because we noticed a lot of the posted PayPal addresses had the different state than the actual address on ZenCart.

Thanks Jeff, think I will have to make the switch. Starting to have problems with my card processor again, need something more reliable and Paypal / Paypal Payments Pro was that. Slightly higher fees per transaction, but not paying the two monthly elsewhere makes it cheaper anyway.

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/community/blog/invalid-resource-id-error-paypal-api/?utm_source=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).

Jeff_Mash:

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/community/blog/invalid-resource-id-error-paypal-api/?utm_source=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".

lat9:

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.

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."

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.

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?

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?
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.

lat9,

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

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

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

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?