Post by Qphoria » Wed Dec 24, 2008 6:34 am

Ok.. I think I've got it.
The Old Paypal won't work with Auto-return/PDT because the old paypal looks for POST vars and the AutoReturn/PDT combo uses GET vars. So I will have to rewrite the entire callback function to support Autoreturn/PDT and non-autoreturn with POST vars.

IPN stuff isn't changing, however there was a url formatting bug that was uncovered in the testing, which might explain why IPN never seemed to be working for me.

Stay tuned!

Image


User avatar
Administrator

Posts

Joined
Tue Jul 22, 2008 3:02 am

Post by Qphoria » Wed Dec 24, 2008 10:19 am

There are 3 configurable options in everyone's paypal account
Autoreturn - This will automatically return to your site after payment is made, instead of requiring your customer to "Click to Return". When Autoreturn is enabled it uses GET variables. If Autoreturn is disabled, the manual "Click to Return" is used, and can be set to use GET or POST variables.
Payment Data Transfer (PDT) - This will append GET variables to your "return" url regarding the payment. This can be used for verification as well as it supports a handshake method to ensure the data is correct. PDT requires autoreturn to be enabled, which means it uses GET variables.
PayPal Account Optional - If your customer doesn't have an account, it allows you to let them create an account from the paypal login page. WARNING. If you use this, autoreturn will NOT work. They will bypass the autoreturn page and go into their account and have to manually "Click to Return" to get back to your site. It's a dumb paypal quirk.

Now, IPN is the backbone of all of these. IPN is enabled via the commands in the paypal module, so you don't need to enable them, however, if for some reason IPN fails, then we'd want the most effecient backup method from the above options.

So I could support a bevy of combinations, or I could just require one configuration... Lets go over some scenarios to see what we have here.

Scenario 1: (THIS IS HOW THE OLD PAYPAL WORKED)
Auto-Return=N
PDT=N/A
PayPal Account Optional=N/A
Customer Has account=Y
(method=POST)
--- Customer clicks Pay Now on Paypal site
--- If customer clicks "Return to Merchant"
------ message posted back to your callback for processing.
--- If customer doesn't click "Return to Merchant"
------ relies only on IPN to process order. If IPN fails, the order is paid for but not processed


Scenario 2 (BEST METHOD):
Auto-Return=Y
PDT=Y
PayPal Account Optional=N
Customer Has account=Y
(method=GET)
--- Customer clicks Pay Now on Paypal site
--- Autoreturns to your site to your "return" url
--- PDT appends GET variables to your url that you can use to create a handshake message
--- OpenCart sends the value back to Paypal in the background
--- Paypal replies with "SUCCESS"
--- Order is processed and put into correct state

Scenario 3:
Auto-Return=Y
PDT=Y
PayPal Account Optional=Y
Customer Has account=N
(method=GET)
--- Customer creates paypal account
--- Customer Pays Now on Paypal site
--- Autoreturn doesn't work so customer has to click "Return to Merchant"
--- IF customer clicks it
------ PDT appends GET variables to your url that you can use to create a handshake message
------ Post the value back to Paypal
------ Paypal replies with "SUCCESS"
--- IF customer doesn't click it
------ Better hope IPN worked, otherwise the order is paid for but not processed

Scenario 4:
Auto-Return=Y
PDT=Y
PayPal Account Optional=N
Customer Has account=N
(method=GET)
--- Customer told that he must first make an account before checking out.
--- Order not processed.
--- Customer has nothing else to do but return to site and comeback when he has a paypal account or choose a diff payment option.


Scenario 1 is the original opencart paypal way, it relies solely on IPN
Scenario 2 is known as the "Belt & Suspenders" method, where it has 2 reliable methods supporting eachother: IPN and Autoreturn. This is the best option.
Scenario 3 is questionable, because while you are allowing customers to create an account during the checkout process, you are losing the supporting leg of the auto-return abilities.
Scenario 4 looks bad, but really if a customer doesn't have a paypal account, he will likely not choose that payment option anyway. Or if he really wants to make an account, then he can do so, and come back to finish checking out and get the benefits of Scenario 2.

So there are many scenarios here. I could code to support them all, or I could code to support Scenario 2 (and 4) and require store owners to enabled Autoreturn & PDT for it to work best, otherwise they are reliant on IPN only.
Last edited by Qphoria on Wed Dec 24, 2008 11:20 am, edited 1 time in total.

Image


User avatar
Administrator

Posts

Joined
Tue Jul 22, 2008 3:02 am

Post by Qphoria » Fri Dec 26, 2008 11:44 am

Well it's a Christmas Miracle! I got paypal working smooth as a greased up deaf guy:P

It took me all this time to realize why IPN never seemed to work. In fact IPN NEVER could have worked for anyone... EVER!

The paypal->process() function was only called on "Click to Return".
The paypal->process() function loads the order from the temp table into the real order table with "Paid Unconfirmed" state

The paypal->callback() function was called on IPN return.
The paypal->callback() function updates the order from "Paid Unconfirmed" to "Pending"

IPN return is instant.. click to return is not.
Therefore, callback was trying to update an order that didn't exist yet because it was happening before the order was ever processed!

Now that I got that working, the paypal module is rocking hardcore!
- PDT working 100% on the front end (with validation security steps)
- IPN working 100% on the back end
- New security validation using custom fields and paypal handshakes
- New admin config option for declaring PDT token
- New admin config option for choosing authorize only or instant sale
- New admin config option for enabling debug information to write to file for troubleshooting.
- New admin config information about how to set up your paypal account to work with the paypal module
- Allows setting the "final order state" to something other than "Pending", based on the value in the language file.

Also
- added support for proper payment process check. This is for ALL payment modules, not just paypal. Before, even if the payment failed, the checkout_process index function would still process the order and take you to checkout_success. Now the payment module can return true or false and change the outcome. I believe this can be used to replace the checkout_pending security method, making checkout less clunky.

I am cleaning up the code now and it should be checked into SVN by tomorrow. It will be included with 0.7.9 RC6 and hopefully we can get 0.7.9 final out by new year!

"Every time a bell rings, a paypal module gets it's wings"
Last edited by Qphoria on Fri Dec 26, 2008 11:53 am, edited 1 time in total.

Image


User avatar
Administrator

Posts

Joined
Tue Jul 22, 2008 3:02 am

Post by Qphoria » Sun Dec 28, 2008 11:39 am


Image


User avatar
Administrator

Posts

Joined
Tue Jul 22, 2008 3:02 am
Who is online

Users browsing this forum: No registered users and 8 guests