PayPal RESTful API Payment Module

lat9:

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).
Thanks for the files; I'd never validated a major reduction in cost (i.e. 346.83 going to 15.00). I'll play with that locally later today to see what's up.

Thank you. This is a regular occurence for us. The customer wants to add something to their order, so we have likely already captured the original amount (in this case, $346.83) and we just want to **add **(Re-authorize) an *additional *$15 for the item being added to the order.

apollowilcox:

Thank you. This is a regular occurence for us. The customer wants to add something to their order, so we have likely already captured the original amount (in this case, $346.83) and we just want to **add **(Re-authorize) an *additional *$15 for the item being added to the order.
The ability to re-authorize depends on whether/not the previous capture was indicated as the final one. Note also that the 'additional' $15.00 is actually an increase in the amount authorized -- in the case you identified, you'd re-auth for $361.83.

Thanks for that clarification of how the re-auth works. This is different than how the authorize.net re-auth works - for that one, you only enter the *additional *amount.

We're going to give up on this. Even with the paypay re-auth, it cannot occur until 72 hours have passed, which kills the effectiveness for the customer calling in with a "change my order quantity from 4 to 5" type of adjustment, as the soonest we could process the additional amount is 3 days later, when otherwise the order might ship today. And paypal re-auth also mentions a 15% limit and a $75 ceiling. Just won't help like the authorize.net re-auth does.

That could be why no one responded to the initial post - it is too impractical for anyone to benefit from.

Thanks Lat9 for your time and knowledge.

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.

Would it be possible to provide the specific fixes needed on lines 782 and 129?

THX!

mikestaps:

Would it be possible to provide the specific fixes needed on lines 782 and 129?

THX!
See this GitHub commit for the changes needed: https://github.com/lat9/paypalr/commit/18009a7728e7942e071f4304006c0752c4102727#diff-5570b3c0c9736e7da16fe8c3e642e417cac05c2977e50652d76973e6a662156c

PERFECT! Thank you :smile:

Cindy - Quick question: I know the module no longer uses the IPN Hander. My question is, if we do set an IPN Handler in PayPal (under the Settings --> Notifications), would that interfere with the module in any way?

I ask because we are developing a product (completely separate from ZenCart but run on our same server), and this other product uses a PayPal button that relies on PayPal to post back to the IPN handler for that program.

So if we put the URL for that other program into our PayPal IPN settings, would that somehow cause our ZenCart store (using the PayPal RESTFUL api) to stop processing the orders?

Jeff_Mash:

Cindy - Quick question: I know the module no longer uses the IPN Hander. My question is, if we do set an IPN Handler in PayPal (under the Settings --> Notifications), would that interfere with the module in any way?

I ask because we are developing a product (completely separate from ZenCart but run on our same server), and this other product uses a PayPal button that relies on PayPal to post back to the IPN handler for that program.

So if we put the URL for that other program into our PayPal IPN settings, would that somehow cause our ZenCart store (using the PayPal RESTFUL api) to stop processing the orders?
The /ipn_main_handler.php processing has no bearing on the PayPal RESTful module's operation. Just be sure that you grab the current version of that file from the Zen Cart GitHub as there have been a bunch of changes since zc210 to correct various PHP warnings and notices in that file.

Funny finding - I logged in to PayPal to set this up, then logged out, then in the same browser, attempted to run a test transaction, and got:

You are logging into the account of the seller for this purchase. Please change your login information and try again.

So if you're testing storefront checkout right after getting your API and Secret keys, it might be a good idea to use another browser for the test. (Unless you're willing to clear cache and cookies, of course.)

Was having all kinds of problems on a test 2.2.0a with the latest GitHub until adding the changes to includes/functions/functions_osh_update.php.

One of them was that Zen Cart was reporting my address to PayPal as the store address, versus the correctly entered address.

Still having a 404 error with no log created when, in the PayPal browser, clicking on return to the store.

ZC 2.2.0a
PHP 8.4
Bootstrap 3.77
Edit Orders 5.0.2
PayPalr 1.2.0 beta
OPC 2.5.4

dbltoe:

Was having all kinds of problems on a test 2.2.0a with the latest GitHub until adding the changes to includes/functions/functions_osh_update.php.

One of them was that Zen Cart was reporting my address to PayPal as the store address, versus the correctly entered address.

Still having a 404 error with no log created when, in the PayPal browser, clicking on return to the store.

ZC 2.2.0a
PHP 8.4
Bootstrap 3.77
Edit Orders 5.0.2
PayPalr 1.2.0 beta
OPC 2.5.4
That's what you get when you use a pre-release of a plugin in conjunction with an alpha-release of Zen Cart itself. If you choose to be a beta-tester, I'll suggest that you post your findings on the PayPal RESTful GitHub repository (https://github.com/lat9/paypalr).

v1.2.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 these GitHub issues:

#78: Add Package Tracking via v2 Orders API
#73: Admin Email Alert: Payment Error "Order Requires Attention"
#67: Error 409 not caught when duplicate requests sent
#64: Include additional seller and buyer details in transactions
#60: Refund status ID: should default to Pending as fallback
#58: Customer's IP address shouldn't participate in GUID generation
#56: ppr_webhook_main is more of a redirector than a webhook handler
#55: New/changed configuration settings not applied on initial installation
#54: Encapsulation preparation, copy/delete ppr_webhook_main.php on install/remove
#53: 'MODULE_PAYMENT_PAYPALR_PAYER_EMAIL' is duplicated in language file
#51: Month dropdown can have repetitive months on the 29-31 of a given month
#23: Disable admin confirmation buttons, once clicked

Hi there,
I have tried the latest github releases and now the 1.20 on plugins. I think it must be my template, or maybe as I am uk based? I see the helios in url where it processes the card. It just goes to the home page after that, sometimes it just got stuck on the rotating circle gif. But I gone back to 1.1 and all okay, I am not affected by any of the fixes as far I know. Just thought I would let you know in case, I think the user base is mostly outside of UK right now.

HeathenMagic:

Hi there,
I have tried the latest github releases and now the 1.20 on plugins. I think it must be my template, or maybe as I am uk based? I see the helios in url where it processes the card. It just goes to the home page after that, sometimes it just got stuck on the rotating circle gif. But I gone back to 1.1 and all okay, I am not affected by any of the fixes as far I know. Just thought I would let you know in case, I think the user base is mostly outside of UK right now.
Is this with the built-in 3-page checkout or with the one-page checkout plugin? Please supply the Zen Cart and, if using, OPC versions.

I've verified PayPal/Restful's operation on both and am trying to understand the source of the issue.

lat9:

Is this with the built-in 3-page checkout or with the one-page checkout plugin? Please supply the Zen Cart and, if using, OPC versions.

I've verified PayPal/Restful's operation on both and am trying to understand the source of the issue.

I am using OPC 2.55 (august) and zencart 2.10, if that helps. It does the first bit in url, but 1.1 restful it seems to process at bank okay (looking at url).

HeathenMagic:

I am using OPC 2.55 (august) and zencart 2.10, if that helps. It does the first bit in url, but 1.1 restful it seems to process at bank okay (looking at url).
If you would turn on PayPal/Restful's debugging and try with v1.2.0 again, I'd appreciate it. I'll send you my direct email address via PM and you can send the paypalr-*.log file that's generated.

Error file not found. ppr_listener.php?op=return&token=xxxxxxxxxxxxxx&PayerID=xxxxxxxxxxxxxx

Zen Cart 2.1.0
PHP 8.3.23
OPC 2.5.4
Bootstrap 3.7.4
PayPal RESTful 1.2.0 (upgraded from v1.1.0)

Auth Only (All Txns)
Credit cards true

mprough:

Error file not found. ppr_listener.php?op=return&token=xxxxxxxxxxxxxx&PayerID=xxxxxxxxxxxxxx

Zen Cart 2.1.0
PHP 8.3.23
OPC 2.5.4
Bootstrap 3.7.4
PayPal RESTful 1.2.0 (upgraded from v1.1.0)

Auth Only (All Txns)
Credit cards true

Hmm, that file "should" have been copied to the site's root on the upgrade from 1.1.0 to 1.2.0. Did you navigate to the admin's Modules :: Payment after you copied the updated file-set?

lat9:

Hmm, that file "should" have been copied to the site's root on the upgrade from 1.1.0 to 1.2.0. Did you navigate to the admin's Modules :: Payment after you copied the updated file-set?

Yes, I did. Even uninstalled & reinstalled in admin