Correct assumption.Quote:
Originally Posted by brittainmark
Printable View
Correct assumption.Quote:
Originally Posted by brittainmark
Thanks, thats great to know! It seems to work okay so far. Would be nice if any other UK users chimed in, but am expecting it to be more reliable than what I am using now via one of the payment gateway companies.Quote:
Originally Posted by lat9
I tried disabling IPNs from the PayPal account (removed the soap method from PayPal), it made no difference. I managed to stop the error by setting PayPal Express checkout to 'False' rather than 'Retired'. I now don't know if this is a paypal issue or a zen cart issue?Quote:
Originally Posted by brittainmark
I am using zen cart 2.0.1 php 8.3
Still getting error even with PayPal express set to false. It even occurs when I void a transaction made with PayPal restful.
Thinking of deleting ipn_main_handler.php.
Thoughts?
I'll try again tomorrow to see if it is a delay at paypal removing the soap method.
Somewhere in your PayPal Merchant settings is a URL to which any IPN notifications are to be sent. Clear that out.
Done that. It is under account settings>notification>Instant Payment Notifications I have deleted and disabled. Unless it is not instantaneous, I still have issue.
Will look to see if I can find it anywhere else.
I have turned it off and still seeing messages.
Have just found this on paypal site.
Does paypal restful send a prefered ipn when a request is issued?Code:The IPN message is always sent to your notification URL unless you have disabled the preference to receive IPN
messages. Even though you have not enabled receiving IPN messages in your Profile or you have reset your preference by
turning off IPN messages, PayPal still sends IPN messages to the notification URL you specify for a specific payment. IPN
messages not sent because you disabled the preference in your Profile will appear in the IPN history when you enable
receiving IPNs. After they appear in the history, you can choose whether to resend them.
PayPal Restful has no IPN interface, neither in its request nor response.Quote:
Originally Posted by brittainmark
Think I may have to talk to PayPal.
If/When I havea solution, I'll repost.
Thanks for the input.
Not sure, I have completely got to the bottom of it. 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.
Paypal are looking to see if why they are still sending IPN messages.
I don't see where this is solved. I have this similar issueQuote:
Originally Posted by swguy
Zen Cart 2.1.0
PHP 8.3
OPC 2.5.4
Boot 3.7.4
PayPal RESTful 1.0.5
ThanksQuote:
2025-01-13 09:46:08: (checkout_one_confirmation) ==> End confirmPaymentSource
2025-01-13 09:46:08: (checkout_one_confirmation) pre_confirmation_check, sending the payer-action off to PayPal.
************************************************
************************************************
2025-01-13 09:46:10: (index) ppr_webhook_main (cancel, live) starts.
{
"op": "cancel",
"token": "xxxxxxx",
"main_page": "index"
}
************************************************
2025-01-13 09:46:10: (checkout_one) validateCredentials: Checking (1).
TokenCache::get, using saved access-token; expires in 30171 seconds.
************************************************
Melanie
@mprough, the PayPal log you supplied would indicate that the customer cancelled the transaction at PayPal.
I didn't, see belowQuote:
Originally Posted by lat9
Attachment 20866
Attachment 20864
@mprough, is there any more to that paypalr log than what you posted? If so, please post as I don't have sufficient information to investigate the root-cause of the issue.
PM sentQuote:
Originally Posted by lat9
What browser is in use when the issue shows itself? Any browser add-ons?
Chrome fully up to date, some dev plugins like measure it & color pickerQuote:
Originally Posted by lat9
BUT, I have other client's websites same version everything with no issue. Same server. Only difference I can see is this one does not use credit cards, only PP.
I can use PayPal today, tested, same PP version 1.0.5, ZC 2.1.0 & same server. successful
Wow, that makes absolutely no sense to me ... unless PayPal was having a bad day.Quote:
Originally Posted by mprough
You have the link, want to try & see if you can get to PP? The error at PP is just after loginQuote:
Originally Posted by lat9
... and if it's successful, someone will issue a refund?Quote:
Originally Posted by mprough
FWIW, I made it to PayPal's confirmation page. Does that count as a success?Quote:
Originally Posted by lat9
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 workingQuote:
Originally Posted by lat9
You logged in to PP? Right after I login I get the go back error providedQuote:
Originally Posted by lat9
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: Attachment 20869
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?
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.Quote:
Originally Posted by lat9
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.
Attachment 20870
Attachment 20871
Attachment 20872
Hi Jeff,Quote:
Originally Posted by Jeff_Mash
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.Quote:
Originally Posted by HeathenMagic
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.Quote:
Originally Posted by 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/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".Quote:
Originally Posted by Jeff_Mash
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.Quote:
Originally Posted by lat9
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
Quote:
***--> 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"
}
}
}
Quote:
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?
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.Quote:
Originally Posted by JG64
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):
Code:CreatePayPalOrderRequest::__construct(card, ...) finished, request:
...
'payment_source' =>
'attributes' =>
array (
'verification' =>
array (
'method' => 'SCA_ALWAYS',
),
),
),
),
Code: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).
Code: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"
}
Code: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?
There is 3DS support. PayPal will send a 3DS request if it warrants it. That comes back through the webhook in the root.Quote:
Originally Posted by balihr
See this PayPal testing documentation for details: https://developer.paypal.com/api/res.../card-testing/
Cindy - Something appears to be happening right now, and I'm not sure if anyone else is experiencing this. 1.5.8a running the 1.0.5 version of the module.
I just noticed between last night and today that the module is disabled (after working fine).
I just enabled it again, and moved a pending (authorized only) order to a new ZenCart status (processing), and the module disabled again.
It gave this message: " The live credentials for the paypalr payment module are invalid. The payment module has been automatically disabled."
I logged into PayPal's Developer Portal and noticed that the setting was on Sandbox instead of LIVE (we didn't change this, so I don't know why it was on Sandbox mode).
I put it back to live mode, and made sure the credentials were correct in the module. But it keeps disabling. HELP!
EDIT - When I look in PayPal and edit the credentials to see the details, I see this:
Attachment 20912
Could that be the issue, and what would cause that?
Please use the curl tester at YOURDOMAIN.COM/extras/curltester.php to test over and over again to see if you get intermittent result on connection for "PayPal Express/Pro Server" and the "PayPal Express/Pro Sandbox"
It appears to be failing in some areas....see screenshot.Quote:
Originally Posted by barco57
Attachment 20917
Thanks Cindy. I've spent all day trying to get this to work, but whatever I do, PayPal always responds with 3ds_return, even when I cancel the transaction during 3DS verification. I give up in hope someone smarter than me (it's not like I've set the bar high...) sorts it out in the future.Quote:
Originally Posted by lat9
Based on what I can tell, 3DS is there, but not working. Since the module isn't checking for the 3DS response nor the EnrollmentStatus, Authentication_Status and LiabilityShift parameters at all, all transactions are authorized by default (speaking of 3DS only), meaning all liability falls down to the merchant. Please correct me if I'm wrong.
In case anyone else is having CURL Connection Issues to the PayPal REST server.......
The issue in our case was that the FIREWALL was blocking a list of countries that are high risk for hacking, fraud, and malicious behavior. It turns out that RUSSIA being in the CC_DENY list for our firewall was the issue.
Why? No idea. Russia (RU) has been in our ban list for over a year with no issue. But suddenly, as of February 19th, 2025, it appears that there is some kind of relationship between Paypal REST servers and Russia.
When we REMOVED the "RU" country from CC_DENY on our firewall, wallah! We could connect to the PayPal REST server. When we put RU back on the list, the connection couldn't be made.
Hopefully that can help someone else out there. Thanks to Cindy for helping to rule out all the other issues we thought it could be. <3
There are reports from several merchants that the intermittent issue happening earlier today and yesterday may be resolved.
Hopefully it has indeed been fixed. My last interaction with PayPal about it indicated that it was being escalated to a senior engineer to investigate.
v1.1.0 of the PayPal RESTful payment module is now available for download: https://www.zen-cart.com/downloads.php?do=file&id=2382
This release contains changes associated with the following GitHub issues:
#24: Display card payments' AVS/CVV status in the admin.
#48: Correct function signature.
#25: Add `Auth Only (Card Only)` transaction type.
#49: Add setting to enable `SCA_ALWAYS` on card payments and capture 3DS status from PayPal.
Is Update from 1.0.5 just a straight overwrite of the existing files? Or do I need to uninstall and reinstall?
Ignore me just found the read me. Simply overwrite the existing installation. Thanks
zc 1.58a
php 7.4
opc 2.5.1
paypal RESTful 1.1.0
Received error log below after installing and testing paypal RESTful. We had a nearly identical error on a test site with zc 2.1.0 and php 8.1 using a database only upgrade from a copy of the 158a database. Maybe a database issue?
[16-Mar-2025 17:32:48 UTC] Request URI: /index.php?main_page=checkout_process, IP address: 71.200.5.177, Language id 1
#1 trigger_error() called at [/includes/classes/db/mysql/query_factory.php:703]
#2 queryFactory->show_error() called at [/includes/classes/db/mysql/query_factory.php:648]
#3 queryFactory->set_error() called at [/includes/classes/db/mysql/query_factory.php:289]
#4 queryFactory->Execute() called at [/includes/functions/database.php:133]
#5 zen_db_perform() called at [/includes/modules/payment/paypalr.php:1898]
#6 paypalr->after_order_create() called at [/includes/classes/payment.php:306]
#7 payment->after_order_create() called at [/includes/modules/checkout_process.php:103]
#8 require(/includes/modules/checkout_process.php) called at [/includes/modules/pages/checkout_process/header_php.php:13]
#9 require(/includes/modules/pages/checkout_process/header_php.php) called at [/index.php:35]
--> PHP Fatal error: MySQL error 1364: Field 'business' doesn't have a default value :: INSERT INTO paypal (order_id, txn_type, module_name, module_mode, reason_code, payment_type, payment_status, invoice, mc_currency, first_name, last_name, payer_email, payer_id, payer_status, receiver_email, receiver_id, txn_id, num_cart_items, mc_gross, date_added, last_modified, notify_version, expiration_time, memo, address_name, address_street, address_city, address_state, address_zip, address_country, payment_date, payment_gross, payment_fee, settle_amount, settle_currency, exchange_rate) VALUES ('9956', 'CREATE', 'paypalr', 'CAPTURE', '', 'paypal', 'CAPTURED', xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
17:32:47', '14.84', '1.01', '13.83', 'USD', null) ==> (as called by) /includes/functions/database.php on line 133 <== in /includes/classes/db/mysql/query_factory.php on line 703.
Any help would be appreciated.
Thanks
I don't know the history of your site, but for a zc158a (and later) site's paypal table, the business field is defined asQuote:
Originally Posted by lsde
Updating your database to use the expected 'schema' for that table's field will correct the issue that you've posted.Code:varchar(128) NOT NULL default ''
Upgrade from 1.5.7 to latest github
PHP 8.3
OPC
PayPal RESTful
USPS RESTful
EO
OPC
Accept Credit Cards set to Yes
Users are getting an error message stating the CC must be at leastr 18 characters. Adding dashes to the CC# stops that, but then the process fails as expected.
Set the debug on an got nothing but a series ofCode:() validateCredentials: Checking ().The curlPost (v1/oauth2/token) request was successful (200).
ON my checkout page, The CC icons spill out of the frame with Discover overlapping the next payment option. I tried uploading a screen shot but got "you have exceeded your limit". wlcartistry.com is the live site. This issue sounds familiar but I could not find anything by searching this thread.
ZC 2.0.1
OPC
Paypal Restful
Zelle
IH
Bootstrap
Clone a Template
Edit Orders
DBIO
Attachment 20950Quote:
Originally Posted by g2ktcf
You would just need to increase the width of the div that contains the icons. I'm not familiar with the Bootstrap template but the code you are looking for is
Increasing the width to say 14rem should do itCode:.ppr-button-choice label {
cursor: pointer;
height: 4rem;
font-weight: bold;
width: 11rem;
display: inline-block;
text-align: center;
}
Attachment 20951
That css code is shown as being inline so I'm not sure where it's located, perhaps in some javascript. The simplest way (perhaps the best?) is to add this to the end of your stylesheet.css
Code:.ppr-button-choice label {
width: 14rem!important;
}
That did it. Added that last bit to /includes/templates/WLC_Bootstrap/css/site_specific_styles.php.
Thank You!
You've apparently got Configuration / Minimum Values / Credit Card Number set to 18 (for whatever reason).Quote:
Originally Posted by dbltoe
Quote:
Originally Posted by simon1066
Thanks to both of you! FWIW, I've captured this in one of the payment-modules "Frequently Asked Questions": https://github.com/lat9/paypalr/wiki...sked-QuestionsQuote:
Originally Posted by g2ktcf
I just noticed something interesting. My live store is ZC 2.0.1 and my dev site is 2.1.0.
I did NOT have the same issue in 2.1.0. Once I installed Paypal Restful, the checkout page was correct from the start.
I'm just curious if anyone can reproduce this confirmed issue with PayPal Restful v1.1.0 Beta-1 with OPC v2.4.6.
In the Admin, set your transaction for AUTHORIZE (so you won't actually be charged anything).
Place an order using the GUEST checkout (for the One Page Checkout plug). Use a different state than the current state of your store location.
After your order is in your system, pull up the DETAILS by clicking the "Click for Additional Payment Handling Options" link, and hit the DETAILS button.
See if the STATE being passed to PayPal is correct or not.
For me (using ZC 1.5.8a), it will ALWAYS pass "CA" to PayPal if the user is checking out as a GUEST account only.
(If they are not checking out as a guest account, then it works fine and the correct state is passed to PayPal).
I have reported this in the GitHub but figured I'd post here in case any other users may be seeing this same behavior (with it posting the wrong State only if using a GUEST checkout.
The option has the following code embedded.Quote:
Originally Posted by lat9
How it got there is anyone's guess.Code:18) {redacted}
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