The Google Checkout module is a payment extension module for OpenCart 0.7.9.
This payment module sends the order total and order reference to the Google Checkout payment gateway, and OpenCart sets the order status to 'Paid Unconfirmed'.
Once Google receives the order successfully, it sends a 'new-order-notification' message to the OpenCart web service. This event causes OpenCart to create a new database entry for storing OpenCart's order reference and Google's corresponding order number, so as to be able to find the correct order whenever Google posts more messages to the OpenCart web service.
After Google has successfully processed the payment, it sends a 'charge-amount-notification' message to OpenCart, which then causes OpenCart to change the order status from 'Paid Unconfirmed' to 'pending'.
If Google cancels the order, it sends a 'order-state-change-notification' message, with a new fincancial order state of 'Cancelled'. This causes OpenCart to set its order_status to 'Canceled' and to remove the Google order number from its database.
Download available from http://www.opencart.com/contribution/in ... tion_id/76
Just a reminder to make sure the /logs directory is not publicly accessable after an install of this module:
Use your FTP-client's 'chmod' command to change these access rights.
Code: Select all
user group other
/logs rwx r-x ---
/logs/googleerror.log rw- r-- ---
/logs/googlemessage.log rw- r-- ---
Export/Import Tool * SpamBot Buster * Unused Images Manager * Instant Option Price Calculator * Number Option * Google Tag Manager * Survey Plus * OpenTwig
Doesn't hurt to have one in there, too. But you still have to change the access rights for the 2 log files!Should there be an empty index.php in this folder to prevent directory index?
Export/Import Tool * SpamBot Buster * Unused Images Manager * Instant Option Price Calculator * Number Option * Google Tag Manager * Survey Plus * OpenTwig
I have uploaded a new version of the Google Checkout which fixes a bug similar to the one for the PayPal payment extension, as described in
http://forum.opencart.com/index.php/topic,2163.0.html
You can get it from
http://www.opencart.com/contribution/in ... tion_id/76
http://forum.opencart.com/index.php/topic,2163.0.html
You can get it from
http://www.opencart.com/contribution/in ... tion_id/76
Export/Import Tool * SpamBot Buster * Unused Images Manager * Instant Option Price Calculator * Number Option * Google Tag Manager * Survey Plus * OpenTwig
Ok I've run into a bug.... Technically it's an opencart "weakness" and your contrib is actually breaking other contribs. But the fix will break your contrib if you don't make a change as well.
You are using the new "payment_form_enctype" session override feature to change the enctype to "application/x-www-form-urlencoded"
It was a work around to prevent having all other payment contribs be updated to support a new $enctype view variable that I originally needed for Authorize.net SIM. Glad you are finding it useful too 
But because you are doing it in the construct, it loads on the payment select page as part of listing all the available payment types. So when using a payment type that doesn't specify a special enctype, it is using the new session override version when it shouldn't, and it is breaking the form enctype. This really this does open up a weakness in OpenCart and that session variable should really be cleared before loading the selected payment method, so that it can be reset only if the selected payment module needs it.
I originally designed that feature to be set inside the getActionURL function, as that is a spot that is only called from the selected payment module on the confirm page.
To fix opencart's weakness, I can add a $session->delete('payment_form_enctype'); to the checkout_confirm.php which will clear it before checking the getActionURL on the selected payment type. But that will break your contrib because it never calls the construct for the payment module after the page begins to load. So it will set it before i delete it and then it won't exist
The getActionURL function is called from within that page, and confirms the payment module matches up with its enctype so that is why I found this to be the ideal spot for this setting.
In my AuthNet SIM contrib I set it like this:
You are using the new "payment_form_enctype" session override feature to change the enctype to "application/x-www-form-urlencoded"
Code: Select all
class PaymentGoogle extends Payment {
function __construct(&$locator) {
$this->address =& $locator->get('address');
..........
$this->language->load('extension/payment/google.php');
[color=red]$locator->get('session')->set('payment_form_enctype','application/x-www-form-urlencoded');[/color]
}But because you are doing it in the construct, it loads on the payment select page as part of listing all the available payment types. So when using a payment type that doesn't specify a special enctype, it is using the new session override version when it shouldn't, and it is breaking the form enctype. This really this does open up a weakness in OpenCart and that session variable should really be cleared before loading the selected payment method, so that it can be reset only if the selected payment module needs it.
I originally designed that feature to be set inside the getActionURL function, as that is a spot that is only called from the selected payment module on the confirm page.
To fix opencart's weakness, I can add a $session->delete('payment_form_enctype'); to the checkout_confirm.php which will clear it before checking the getActionURL on the selected payment type. But that will break your contrib because it never calls the construct for the payment module after the page begins to load. So it will set it before i delete it and then it won't exist
Code: Select all
[color=red]$session->delete('payment_form_enctype');[/color]
$view->set('payment_url', $payment->getActionUrl($session->get('payment_method')));
if ($session->get('payment_form_enctype')) {
$view->set('payment_form_enctype', $session->get('payment_form_enctype'));
}
In my AuthNet SIM contrib I set it like this:
Code: Select all
function getActionUrl() {
[color=red]$this->session->set('payment_form_enctype', "text/plain");[/color]
if (!$this->config->get('authnetsim_test')) {
return 'https://secure.authorize.net/gateway/transact.dll';
} else {
return 'https://test.authorize.net/gateway/transact.dll';
}
}
Last edited by Qphoria on Tue Nov 18, 2008 5:03 am, edited 1 time in total.
Another question.
Doesn't the google checkout TOS require that theckout button be on the cart page, and before the user needs to login, essentially forcing all the user info at the google site, which then sends all the info back to the main site after payment. This is the same thing for Paypal express. Doesn't this go outside of that since it uses the post-login method?
Doesn't the google checkout TOS require that theckout button be on the cart page, and before the user needs to login, essentially forcing all the user info at the google site, which then sends all the info back to the main site after payment. This is the same thing for Paypal express. Doesn't this go outside of that since it uses the post-login method?
Well, with the impending release of RC4, I've had to add this security fix for the payment_form_enctype override to svn. This pretty much breaks Google Checkout altogether until the session var set is moved to the getActionURL.
I hope you can get to this soon
I hope you can get to this soon
I'll take a look at it and come back to you on it as soon as possible.
Export/Import Tool * SpamBot Buster * Unused Images Manager * Instant Option Price Calculator * Number Option * Google Tag Manager * Survey Plus * OpenTwig
I have ran some tests with a modified google.php:
Commenting out the payment_form_enctype doesn't seem to make any difference because it then uses the default value for the form submission from the checkout_confirm page which is the 'multipart/form-data', hard-coded in the checkout_confirm.tpl file. The process function doesn't expect any posted values, it takes what it needs directly from the $locator->get('order').
Code: Select all
function __construct(&$locator) {
$this->address =& $locator->get('address');
$this->cart =& $locator->get('cart');
$this->config =& $locator->get('config');
$this->currency =& $locator->get('currency');
$this->customer =& $locator->get('customer');
$this->database =& $locator->get('database');
$this->language =& $locator->get('language');
$this->mail =& $locator->create('mail');
$this->order =& $locator->get('order');
$this->request =& $locator->get('request');
$this->response =& $locator->get('response');
$this->session =& $locator->get('session');
$this->shipping =& $locator->get('shipping');
$this->tax =& $locator->get('tax');
$this->url =& $locator->get('url');
$this->language->load('extension/payment/google.php');
//$locator->get('session')->set('payment_form_enctype','application/x-www-form-urlencoded');
}
Export/Import Tool * SpamBot Buster * Unused Images Manager * Instant Option Price Calculator * Number Option * Google Tag Manager * Survey Plus * OpenTwig
As regards your other question:
I have to look it up, in one of our recently released sites which uses OpenCart and GoogleCheckout (see http://www.dmhcartoons.com) it just uses a general logo at the bottom of the page, without any links.Doesn't the google checkout TOS require that theckout button be on the cart page, and before the user needs to login
Attachments
???Export/Import Tool * SpamBot Buster * Unused Images Manager * Instant Option Price Calculator * Number Option * Google Tag Manager * Survey Plus * OpenTwig
Well, from https://checkout.google.com/seller/policies.html
4. Google Checkout buttons and Buy Now buttons
a. Use standard Google Checkout buttons only
You may only use Google-hosted button images for Google Checkout buttons and Buy Now buttons. You may not alter the size, shape, color, or any other aspect of these images.
b. Ensure 1:1 and adjacent button placement
You should place a Google Checkout or Buy Now button immediately beside, above, or below every existing checkout button or link on your website wherever possible. (Because users tend to read horizontally, we recommend placing the Google Checkout or Buy Now button beside your existing buttons and links.)
You must separate the Google Checkout flow from your existing checkout process. If buyers initiate your existing checkout process, they must not see a Google Checkout or Buy Now button.
If you're using Buy Now buttons, you must display a Buy Now button in a visible and appropriate location for each item you'd like to sell using Google Checkout.
c. Place Google Checkout buttons before your login pages
Buyers should only have to provide their login, purchasing, and other information (including billing and shipping addresses and phone numbers) once. If you require users to register or sign in to your site, you must ensure Google Checkout and Buy Now buttons are available before the login process so buyers are able to check out with Google Checkout without having to log in. (You may still track visits and personalize pages using cookies.)
You may place Checkout buttons after login pages if and only if the following conditions are met:
* Your website exclusively sells digital content and requires a login in order to store the purchased content
All items for sale behind a login must use the digital delivery shipping method as described in our Developer's Guide.
* You display the Google Checkout Acceptance Logo on your website
You must display the Google-hosted Checkout acceptance logo before the login pages of your website so buyers know that Google Checkout is accepted after login.
d. Direct buyers quickly to Google
If you're using Google Checkout buttons, you must ensure that buyers who click the Google Checkout button on your site see the Google Checkout confirmation page within one second, and without seeing any intermediate pages. This will help you avoid shopping cart abandonment. We recommend you consider pre-computing shopping carts, leveraging server to server posting, and other tips in our Developer's Guide.
e. Do not disable the browser's 'Back' button
Buyers who click their browser's 'Back' button should be brought from the Google confirmation page directly back to your site without seeing any intermediate pages. (Learn about server–to-server posting and other best practices in our Developer's Guide.)
f. Identify unsupported purchases
If you're using Google Checkout buttons, you must display the Google-hosted 'not available' button for orders not adhering to our content policies. (Learn more: Google Checkout content policies | Button options)
g. Google Checkout must be available as a checkout option at least 95% of the time
Google Checkout may be unsupported no more than 5% of the time, in which case you are required to display the 'not available' button as described in 4f. At least 95% of the time, Google Checkout must be offered as a checkout option, with the standard Google Checkout button prominently displayed.
h. Direct your 'checkout' links and buttons to the checkout process
Buttons or links containing the word 'checkout' should initiate a checkout process, not a 'view cart' page. The latter may confuse buyers and disrupt the purchase flow.
i. Additional button messaging
Including additional text around the Google Checkout button can help make it clear to buyers that they can check out using either Google Checkout or your existing checkout process. We recommend placing the text “ – Or use – “ between the Google Checkout button and your existing checkout button.
j. Google Checkout for Mobile Buttons
If you intend your site for display on mobile devices you may use lighter-weight, Google-hosted button images as your Google Checkout or Buy Now Buttons. As with standard Google Checkout buttons, you may not alter the size, shape, color, or any other aspect of these images. If you offer an alternative checkout method, you must place a Google Checkout button immediately above, below, or beside every existing checkout button or link on your website. Note that because users tend to navigate vertically when browsing the web with a mobile phone, we recommend placing the Google Checkout buttons below your existing buttons and links.
Aren't the requirements met in view of this:
You display the Google Checkout Acceptance Logo on your website
You must display the Google-hosted Checkout acceptance logo before the login pages of your website so buyers know that Google Checkout is accepted after login.
Export/Import Tool * SpamBot Buster * Unused Images Manager * Instant Option Price Calculator * Number Option * Google Tag Manager * Survey Plus * OpenTwig
Having taken a closer look at Google's T&C and at another Google-approved store (http://www.toysrus.com/) it seems we need to accomplish this:
Provide the Google Checkout without having the OpenCart user to log into the OpenCart store. This wouldn't be too hard, except when it comes to calculating the shipping costs and sales taxes. This opens a can of worms ...
... minutes later trying to figure out a solution......
This means, that the google.php file needs to be amended so that it copies the tax rules and shipping rules into the GoogleCart object in method PaymentGoogle::process(). The OpenCart-Checkout button can only be used for other payment methods, not for Google. Therefore we need a separate GoogleChckeout button (with the image from the Google server) which leads directly to the PaymentGoogle::process() method.
I wonder whether PayPal has similar restrictions.
Provide the Google Checkout without having the OpenCart user to log into the OpenCart store. This wouldn't be too hard, except when it comes to calculating the shipping costs and sales taxes. This opens a can of worms ...
... minutes later trying to figure out a solution......
This means, that the google.php file needs to be amended so that it copies the tax rules and shipping rules into the GoogleCart object in method PaymentGoogle::process(). The OpenCart-Checkout button can only be used for other payment methods, not for Google. Therefore we need a separate GoogleChckeout button (with the image from the Google server) which leads directly to the PaymentGoogle::process() method.
I wonder whether PayPal has similar restrictions.
Last edited by JNeuhoff on Fri Nov 21, 2008 7:58 pm, edited 1 time in total.
Export/Import Tool * SpamBot Buster * Unused Images Manager * Instant Option Price Calculator * Number Option * Google Tag Manager * Survey Plus * OpenTwig
That means it would be useful to have a separate PayPal Express module and a modified Google Checkout module. With both of them not relying on the OpenCart login to function properly.
As I said, the biggest problem will be with the shipping module and tax calculation. I can copy OpenCart's tax rules to equivalent Google tax rules in the payment process function and pass the rules along with the subtotal to Google. It's more tricky with the shipment. The only solution I can think of is to expend the /admin/controller/payment_google.php and the corresponding /admin/template/default/content/payment_google.tpl to include a list of shipping options so that the store owner can set a single shipping method to be used in conjunction with GoogleCheckout. Again, the payment process function would have to copy the shipping cost rules to the Google cart object.
A lot of work.
Maybe if we could continue using OpenCart's login and just make sure that the login e-mail account of a customer is the same he/she uses for the Google Checkout account, then the customer could be re-directed to the Google payment gateway page with most details (e-mail id, address details, etc.) already filled in. I need to get in touch with Google on this, maybe they have a solution to this problem.
... few minutes later, after some more research ...
There is after all a way to solve the problem with the shipping costs according to Google:
As I said, the biggest problem will be with the shipping module and tax calculation. I can copy OpenCart's tax rules to equivalent Google tax rules in the payment process function and pass the rules along with the subtotal to Google. It's more tricky with the shipment. The only solution I can think of is to expend the /admin/controller/payment_google.php and the corresponding /admin/template/default/content/payment_google.tpl to include a list of shipping options so that the store owner can set a single shipping method to be used in conjunction with GoogleCheckout. Again, the payment process function would have to copy the shipping cost rules to the Google cart object.
A lot of work.
Maybe if we could continue using OpenCart's login and just make sure that the login e-mail account of a customer is the same he/she uses for the Google Checkout account, then the customer could be re-directed to the Google payment gateway page with most details (e-mail id, address details, etc.) already filled in. I need to get in touch with Google on this, maybe they have a solution to this problem.
... few minutes later, after some more research ...
There is after all a way to solve the problem with the shipping costs according to Google:
If you have performed a level two API integration, you can specify customised shipping rates, based on counties, postcodes, cities or other criteria, that will be systematically applied to orders in response to the shipping information provided by the buyer. This feature is beneficial if you need the buyer's shipping address in order to calculate item availability or different shipping rates for certain geographic areas. (To learn more about level two API shipping functionality, review 'Specifying Shipping Information' in the Developer's Guide.)
Last edited by JNeuhoff on Fri Nov 21, 2008 10:32 pm, edited 1 time in total.
Export/Import Tool * SpamBot Buster * Unused Images Manager * Instant Option Price Calculator * Number Option * Google Tag Manager * Survey Plus * OpenTwig
I had thought about moving the shipping choice to the cart page, this way it would always update when you updated your cart quantity if selected. That is usually where you find a google checkout button anyway. But that would also mean that we'd need to add a "post code" or "geo zone" lookup form since they user isn't logged in.
That would make it a combined shipping estimator, shipping select, and google checkout/paypal express compatible page. As well as lessen the amount of checkout steps
That would make it a combined shipping estimator, shipping select, and google checkout/paypal express compatible page. As well as lessen the amount of checkout steps
That would be highly useful. How difficult would it be to implement?I had thought about moving the shipping choice to the cart page, this way it would always update when you updated your cart quantity if selected.
That's the tricky part. We'd also need this for the correct sales tax calculation, too. Would you be able to do that? Then I could easily update the Google payment module to retrieve the shipping and taxes from the OpenCart's cart object, or these values could be posted to the PaymentGoogle::process function and then being sent to Google along with the subtotal and order reference as the item description.But that would also mean that we'd need to add a "post code" or "geo zone" lookup form since they user isn't logged in.
In fact a similar solution would probably work for a PayPal Express or any payment gateway which has similar restrictive Terms and Conditions.
BTW. I posted a query on the Google Checkout Developers Forum to find out more about the legal constraints and whether the present payment workflow is allowed. Hope to hear from them soon.
Last edited by JNeuhoff on Sat Nov 22, 2008 12:50 am, edited 1 time in total.
Export/Import Tool * SpamBot Buster * Unused Images Manager * Instant Option Price Calculator * Number Option * Google Tag Manager * Survey Plus * OpenTwig
Who is online
Users browsing this forum: No registered users and 1 guest
