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.

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

[lat9]

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.

[apollowilcox]

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.

[mikestaps]

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.

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

THX!

[lat9]

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/comm...6973e6a662156c

[mikestaps]

PERFECT! Thank you

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

[lat9]

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.

[swguy]

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