PayPal RESTful API Payment Module

lat9:

You've apparently got Configuration / Minimum Values / Credit Card Number set to 18 (for whatever reason).
The option has the following code embedded.```

18. {[B]redacted[/B]}

That redacted stuff is an old javascript injection via the validation that is at minimum 3 years old, and the domain they were posting to has been offline at least that long

Zen Cart 2.1.0
PHP 8.3
Bootstrap 3.7.4
PayPal RESTful 1.1.0

The credit card expiration field, the month of March is there twice, and there is## no expiration option for the month of February.

mprough:

Zen Cart 2.1.0
PHP 8.3
Bootstrap 3.7.4
PayPal RESTful 1.1.0

The credit card expiration field, the month of March is there twice, and there is## no expiration option for the month of February.

I'm guessing that if you use the browser's developers' tools to inspect that dropdown, there's an 02 id for February but the text reads March. That's a weird date-related issue with the base Zen Cart zcDate class.

lat9:

I'm guessing that if you use the browser's developers' tools to inspect that dropdown, there's an 02 id for February but the text reads March. That's a weird date-related issue with the base Zen Cart zcDate class.
Yep, if you navigate to the admin's index.php?cmd=banner_statistics&page=0&bID=0&type=monthly&month=4, you'll see that "Mar" is repeated there, too.

lat9:

Yep, if you navigate to the admin's index.php?cmd=banner_statistics&page=0&bID=0&type=monthly&month=4, you'll see that "Mar" is repeated there, too.

I found the origin of this problem, and it is not ZcDate class, but the way it is used. It is generally called like this:

$zcDate->output('%b', mktime(0, 0, 0, $i)));

Where $i is the month number. Day and year are not given as parameter which means the actual date day and year are used.
Problem is when actual date day is higher than the last day of a month. For PHP it is next month, like 30th of February is actually 2nd of March.
This bug only appears at the end of the month, from 29 to 31! The 31th of the month is worse case where all month less than 31 days (Feb., April, June,Sept. and Nov.) will be set to next month...

Solution is to call zcDate class output like this:

$zcDate->output('%b', mktime(0, 0, 0, $i,1)));

There might be other places in ZC where this needs to be modified...
For this plugin, file paypalr.php needs to be modified on lines 782 and 1269. Line 874 might need it too, not sure yet.

No modification needed on line 874!

pilou2:

I found the origin of this problem, and it is not ZcDate class, but the way it is used. It is generally called like this:

$zcDate->output('%b', mktime(0, 0, 0, $i)));

> Where $i is the month number. Day and year are not given as parameter which means the actual date day and year are used.
> Problem is when actual date day is higher than the last day of a month. For PHP it is next month, like 30th of February is actually 2nd of March.
> This bug only appears at the end of the month, from 29 to 31! The 31th of the month is worse case where all month less than 31 days (Feb., April, June,Sept. and Nov.) will be set to next month...
> 
> Solution is to call zcDate class output like this:
> ```php
$zcDate->output('%b', mktime(0, 0, 0, $i,1)));

There might be other places in ZC where this needs to be modified...
For this plugin, file paypalr.php needs to be modified on lines 782 and 1269. Line 874 might need it too, not sure yet.
Yep, thanks for the follow-up.

lat9:

I'm guessing that if you use the browser's developers' tools to inspect that dropdown, there's an 02 id for February but the text reads March. That's a weird date-related issue with the base Zen Cart zcDate class.

That's a negative ghost rider =) Looks like PayPal fixed it =)

Just started using this module.

Transactions are completing correctly, but I find these in the IPN logs:

May 04 2025 21:14 27 -- IPN FATAL ERROR :: Could not find Zen Cart custom variable in POST, cannot validate or re-create session as a transaction initiated from this store. Might be from another source such as eBay or another PayPal store using this PayPal account.

May 04 2025 21:14 27 -- IPN ERROR :: No saved Website Payments Standard session data available. Must be an Express Checkout or Direct Pay transaction.
Could be a test notification, or the incoming IPN notification is not actually a bonafide PayPal transaction.
NOTE: It is likely that all the following log content is meaningless or irrelevant.
The rest of the data appears ok.

I assume these warnings are due to IPN legacy functions not allowing for this "new" payment module's functionality?

torvista:

Just started using this module.

Transactions are completing correctly, but I find these in the IPN logs:

The rest of the data appears ok.

I assume these warnings are due to IPN legacy functions not allowing for this "new" payment module's functionality?
Those issues have been reported before. My best guess is that you've still got IPN notifications enabled in your PayPal Merchant Center.

Thanks

Those issues have been reported before.

Hmm, I didn't find those in a search.

The setting is in:

Account Settings
Notifications
Instant payment notifications - Update

torvista:

Thanks

Those issues have been reported before.

Hmm, I didn't find those in a search.

The setting is in:

Account Settings
Notifications
Instant payment notifications - Update

Did you double check that your "Instant Payment Notifications" is disabled in your PayPal account?

Go to your PayPal account and go to the Account Settings area.

From the PRODUCTS & SERVICES menu on the left side, select the "Website Payments" link.

From there, click the blue UPDATE button next to "Instant payment notifications".

That will take you to the "Instant Payment Notification (IPN)" page. Scroll to the bottom and hit the "Choose IPN Settings" button.

Make sure it's disabled.

I don't know if that will solve your issue, but it's something that this new PayPal module doesn't use anymore, so you can disable it

I had a similar problem when I moved to restful from paypal api. to solve it I had to contact paypal as even thought I turned off the Instant Payment Notification (IPN) it still send them. They turned if off for me and a day later I stopped getting the Instant Payment Notification (IPN).

Additionally
The issue appears to be that I have log and email turned on in PayPal express checkout. This seems to have stopped the error logs being created.

Jeff_Mash:

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.
This turns out to be a One-Page Checkout issue, where the "state_code" element of an order's address wasn't being updated for any temporary/guest addresses.

See this One-Page Checkout issue for the correction: https://github.com/lat9/one_page_checkout/issues/435

See this One-Page Checkout commit for the required change: https://github.com/lat9/one_page_checkout/commit/74e0923b54b998dfbf5e052c4a12603d8aa43b6b#diff-feef7d5455d9c8e2bdac1e8d5eec40d150d5973e7e9d9c86a897b93b6d7f0212

Note that the change will be released for OPC v2.5.5

This plug-in has a "Re-authorize" button. We are familiar with that function with regard to the authorizenet_cim plug-in where it works effectively for situations when customers call to change their order in some way.

We have never gotten the re-authorize button to work successfully on this paypal plug-in. Is that an issue with our Paypal account setup or configuration? Is the re-auth button working for others?

Thank you.

I just installed Paypal restful on zencart version 1.5.8a about a week ago and followed the instructions to modify the order_total.php. I noticed that I wasn't getting anymore orders from paypal so I decided to try and purchase a test item on my site. During check out everything looked normal and it would bring me to paypal to pay and when I confirmed with paypal what payment method etc I wanted to use it would bring me back to the site. The issue is it would bring me back to the page where you select the payment method. (Paypal or pay with a credit card.) So I would select paypal again and it would just loop like this over and over. There's never a final checkout page. Not sure what is going on so I am going to disable this for the time being and revert back to paypal express checkout.

project jayden:

I just installed Paypal restful on zencart version 1.5.8a about a week ago and followed the instructions to modify the order_total.php. I noticed that I wasn't getting anymore orders from paypal so I decided to try and purchase a test item on my site. During check out everything looked normal and it would bring me to paypal to pay and when I confirmed with paypal what payment method etc I wanted to use it would bring me back to the site. The issue is it would bring me back to the page where you select the payment method. (Paypal or pay with a credit card.) So I would select paypal again and it would just loop like this over and over. There's never a final checkout page. Not sure what is going on so I am going to disable this for the time being and revert back to paypal express checkout.
If you (a) enable the PayPal-r debug-to-file, (b) enable the payment module and (c) reproduce the looping issue, you can then send me a copy of the generated log file so that I can "see" what's going on.

Once you have the debug-log file, PM me for my direct email address.

apollowilcox:

This plug-in has a "Re-authorize" button. We are familiar with that function with regard to the authorizenet_cim plug-in where it works effectively for situations when customers call to change their order in some way.

We have never gotten the re-authorize button to work successfully on this paypal plug-in. Is that an issue with our Paypal account setup or configuration? Is the re-auth button working for others?

Thank you.

Hmmm... no responses. So no one is using the re-authorize button on paypal? Or you do use it and it's working fine for you? Can i get any responses to that? Feel free to PM if you don't wish to post in this thread. Thanks!

apollowilcox:

Hmmm... no responses. So no one is using the re-authorize button on paypal? Or you do use it and it's working fine for you? Can i get any responses to that? Feel free to PM if you don't wish to post in this thread. Thanks!
What is the symptom you're seeing when you say that the feature doesn't "work successfully"? If you could post a few more details, that would be a big help.

Another route to determining what's going on is to enable the log-to-file feature, reproduce an 'unsuccessful' re-authorization and then send me a copy of the generated log file (PM me for my direct email address).