As many of you are aware, Miva Merchant uses a published API for the interface of modules with it. Shipping modules display the applicable methods on the OSEL (shipping/payment selection) page based on the "ship to" location of the customer. The customer selects the method and proceeds to the next page where that specific method is used to calculate the shipping charge.
The Google checkout requires Merchant to send the shipping methods PRIOR to the customer's "ship to" address being known. The author of the module choose to use the store's address as the address to use to determine applicable shipping methods from the installed shipping modules. This list of methods is passed to Google and becomes the list for the customer to choose from. The chosen method is then passed back to Merchant to retrieve a shipping cost.
Problem: If your shipping module displays methods based on "ship to' location, per the API, the only methods the customer will see are the inexpensive local delivery (store's address is used) methods. So a customer in California could select a method applicable to the store's address, eg in New York. The calculation retrieved for this method would be much lower than what you intended. This is the case with all of my zip code and state zone modules. If you decide to use Google checkout and have those modules installed in your store, you need to decide which to abandon. Google does not follow the Miva Merchant API. The "zone" modules do adhere to it.
I would not expect Google checkout procedures to change until they decide to do international orders. At that time they will realize they can't present the methods until the "ship to" address is known.
FWIW, the Google module use of the store's address was not realized by me until someone noted in their mini-basket shipping calculator that the address (state, zip, country) was already filled in but was his address, not the customer's. It took awhile to track down which module was inserting erroneous information into the basketlist database. The Google checkout module author has modified the code to remove the store's address after it retrieves the shipping method list so that fixes the erroneous address showing in the mini-basket. Unfortunately, there can be no fix for the potentially erroneous list of shipping methods being sent to Google unless Google fixes their flow; ie waiting until they get the customer's address before obtaining shipping methods. Course, that is not likely because that would effect all of the Google checkout interface programs written to date.
The Google checkout requires Merchant to send the shipping methods PRIOR to the customer's "ship to" address being known. The author of the module choose to use the store's address as the address to use to determine applicable shipping methods from the installed shipping modules. This list of methods is passed to Google and becomes the list for the customer to choose from. The chosen method is then passed back to Merchant to retrieve a shipping cost.
Problem: If your shipping module displays methods based on "ship to' location, per the API, the only methods the customer will see are the inexpensive local delivery (store's address is used) methods. So a customer in California could select a method applicable to the store's address, eg in New York. The calculation retrieved for this method would be much lower than what you intended. This is the case with all of my zip code and state zone modules. If you decide to use Google checkout and have those modules installed in your store, you need to decide which to abandon. Google does not follow the Miva Merchant API. The "zone" modules do adhere to it.
I would not expect Google checkout procedures to change until they decide to do international orders. At that time they will realize they can't present the methods until the "ship to" address is known.
FWIW, the Google module use of the store's address was not realized by me until someone noted in their mini-basket shipping calculator that the address (state, zip, country) was already filled in but was his address, not the customer's. It took awhile to track down which module was inserting erroneous information into the basketlist database. The Google checkout module author has modified the code to remove the store's address after it retrieves the shipping method list so that fixes the erroneous address showing in the mini-basket. Unfortunately, there can be no fix for the potentially erroneous list of shipping methods being sent to Google unless Google fixes their flow; ie waiting until they get the customer's address before obtaining shipping methods. Course, that is not likely because that would effect all of the Google checkout interface programs written to date.
Comment