Google checkout and shipping module incompatibility

[wcw]

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.

[lbdesign]

Wow. Would it be possible to set up a new table-based shipping method that only Google could see? ie: google checkout would only get the one special shipping method that is weight-based and not zipcode based, and the regular checkout flow would not display that method?

[wcw]

What benefit would that have? The selection list is just a list of methods, not costs. The costs get returned after the customer selects the method. The problem is that the shipping modules MAY not return the methods applicable to the destination for the customer to choose from. If the module restricts what methods are displayed based on "ship to" location, eg a "zone" module, it will not show the correct methods because the "ship to" location is wrong. If you use something like UPS and it displays ALL methods no matter what the zip is, then there won't be a problem.

[lbdesign]

OK. I misunderstood your description of the problem.

[dsisaacs]

Isn't there a way to "force" the customer to fill in their address BEFORE allowing them to click the google checkout button. If so, would this pass the correct list of methods?
I know there is a disabled value available to grey out the google checkout button.

[wcw]

Technically that would be the solution. But I don't think Google allows that.

[Red Flare]

The Google checkout requires Merchant to send the shipping methods PRIOR to the customer's "ship to" address being known.
This is really weird. Why would Google checkout programmers do this?

So, if I am understanding correctly NONE of the shipping modules that come with MIVA will work with Google checkout, except for USPS, UPS and Fedex?

[wcw]

That is not correct. They should display all of their methods because their methods are not dependant on location. Flat rate is flat rate. It doesn't matter if you live in CA or NY. The same methods are shown for every location. It is only when the module is complex enough that it only shows the methods applicable to the "ship to" location. Since it is given the wrong "ship to" location, it shows the wrong methods.

[dsisaacs]

I had a thought about this...
Could you create a new page identical to the BASK page named GBASK.
Modify the Google checkout link on the BASK page to go to another page which asks for the customer zip code, the continue button would then take you to the GBASK page where the Customer would then click on the google checkout button to go to google and pay.
The return path would link to the GBASK page as per the google requirement. Could something like this solve the shipping method issue?

[massbay]

Regarding the first post in this thread by WCW: "...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. ..."

Does this imply that there is an update to the Miva 5 Google module? At our store, the store's own address is still showing up erroneously in the minicart.
If there is an update, how do we download it?

[wcw]

Unfortunately, any updates are now provided by MIVA so you'll have to wait until they bundle up a fix for the bug and distribute it. I don't know if the author has even provided the update to MIVA.

[CLJ]

I just had my first order processed through Google Checkout and the customer didn't pay any shipping at all !!?? Are they allowed to enter 0 for shipping or is there something wrong with the module?

[massbay]

To CLJ-
Log in to your Google account and check your Google Checkout settings in Integration and Integration issues. You may have had a timeout when Google went back to your Miva site to calculate the shipping. If it does not respond within 3 seconds it goes with the default shipping sent over with the shopping cart before Google knew the ship-to address.

[copperlab]

I am having some similar problems. Let me say first that I am having a problem with integration in the the API callback URL isn't working. However, I have left the google checkout buttons on my site and have 3 pending orders (one I did myself). So while this API callback problem is being figured out by my host I figured I would allow orders to just pile up.

So I have recieved these three orders, and only the one I submitted had any shipping charges at all. The others paid no shipping. I use the mini-basked module and haven't changed any of the settings.

So my question is why didn't the API charge them shipping? Can I add shipping after the fact? Does it have to do with the the mini-basket module? Does this problem have to do with the API callback URL problem I am having (I thought this was just to import the completed google order back into MIVA for notification purposes)? How are other people finding a remedy to this problem?

[wcw]

The minibasket module is not related. It does show you the problem though. The address used to report address to google initially is the STORE's address. Some shipping modules will not have any methods for shipping to yourself or the shipping will be dirt cheap. Why no shipping method is selected is anybody's guess. Did you have a shipping method to choose from when you placed your test order that got you free shipping?

[copperlab]

No, No options...just Shiping+Handling $0 that was all it said I don't ship from my store location anyway, I ship from half-way accross the country. What is the work around here?

[wcw]

What shipping modules are you using? Would they provide methods if the ship to address is the store's address?

[copperlab]

I am using the regular old UPS shipping module build into MIVA. My zip code for my address in the domain settings is 55105. The UPS module Origin zip code is 92020. When I place an order using my exact address as in the domain settings it charges the correct shipping.

Here is what I have found. That if I delte all my cookies, and temp. internet files and go to my store: http://store.copperlab.com then put an item into my cart, the minibasket shows the item, and also shows that there is no information in the calculate shipping portion. If I were to go straight to google checkout from there the shipping charges will be $0. However, if in the mini-basket I click on the calulate shipping, then put in the state, country, and zip code, and then click on Google Checkout the shipping charge is correct.

What does this mean? I have no idea? You can test for yourself though...go to http://store.copperlab.com and put item in basket then click on calculate shipping, my zip and state of the store isn't in there. You can't test the google checkout part because I have removed the buttons from the site, I can re-establish them if this would help.

One other question. I had the google checkout button showing up on every page above the mini-basket, I wasn't making people go the the Basket page to click on the standard google checkout button. Could there be a problem with having the google checkout button on the same page that the mini-basket is?

Thanks for your help.

[wcw]

The google checkout button causes it to set the basket shipping address to the store's address, which is rarely the customer's true address. The minibasket is reading that address in the basket. I don't know if the developer of the google module has released an update to fix that discrepancy. The test version I got removed the address right after it sent the bogus address to google. So the minibasket would show prompts for you to enter the correct address instead of relying on the basket being correct, when it was not.

[copperlab]

Okay, I am kinda lost a little here so I am sorry...But this doesn't explain why some of my orders are coming in at $0 shipping. They should at least be calculated to my store zip code 55105?

I guess I just ned this question answered. Is it possible to use google checkout with my store at this time (and have shipping charged). Or are all MIVA customers out of luck for now as far as google checkout is concerned. If I can use it, what steps to I have to take in order for it to work.

Thanks for your help, you have been great :)

[sebenza]

If the order came in with something like "Shipping & Handling $0.00"... this means that Google could not communicate with your callback file and gave the customer the default shipping method.

[wcw]

I think the answer relative to the 0.00 charge is the slow response back from miva merchant to google when the calculate charge is run.

[copperlab]

Okay, I think I have my answer. This goes back to another post of mine. If my API callback function is not working see post http://extranet.miva.com/forums/showthread.php?t=6833 for further information. My shipping will not function properly...So I need to get the API function working...I was hoping that I could just process orders through the google checkout website and not have to wait for my host to figure out the API problem :) ...Do you have any ideas on that problem?

Again, you all have been very helpful....

[copperlab]

Okay, I got the API callback problem figured out on my site. Here is the probelm I am having now. Still has to do with the shipping+handling $0 coming up when a customer goes to google checkout. Here is the new error. And let me throw this in there. I have mini-basket installed on my site. If I were to calculate shipping in the mini-basket first, then go to google checkout everything is fine, shipping comes up as it should. It is only when there is no information in the mini-basket that I get the shipping+handling $0.

Thanks for your help, the error is pasted below.

Feb 11, 2007 1:53:19 PM CST Error:Merchant Calculations: We were looking for data in your merchant-calculation-results, but were not able to find it: result: address-id:964750024468814shipping-name: Standard+Shipping Warnings:XML We Received: _type=merchant-calculation-results&results.result-1.address-id=964750024468814&results.result-1.shipping-name=Standard+Shipping&results.result-1.shipping-rate.currency=USD&results.result-1.shippable=true&results.result-1.shipping-rate=0.00&results.result-1.total-tax=0.175&results.result-1.total-tax.currency=USD

[wcw]

When you use the minibasket first, it sets the correct address for shipping modules to use. If you go to the full basket (with the google button) first, the google checkout module is not using the customer's real address. I was told by the module developer that it is using the store's address. How that effects your shipping module's list of methods, varies by what shipping modules you are using.

[sebenza]

copperlab-
You might have already said... but are you using miva 4 or miva 5?

[copperlab]

Using MIVA 5. All updates are installed. Merchant info is put in correctly on both the MIVA side and the Google side.

I am using the UPS module and have the following add-on moduels:

mini-basket (emporium)
best sellers (emporium)
adendum (emporium)
coupon (emporium)
Merchant Moogle
SEO Links (sebenza)

Thanks for your help.

[copperlab]

Again, the problem is all orders are coming in with Standard+Shipping $0 for the shipping charges. Here is the error reported in the Google Checkout integration website:

Integration Issue Detail
Time of occurence: Feb 11, 2007 1:53:19 PM CST
Error: Merchant Calculations: We were looking for data in your merchant-calculation-results, but were not able to find it: result: address-id:964750024468814shipping-name: Standard+Shipping
Warnings:
XML We Received:


_type=merchant-calculation-results&results.result-1.address-id=964750024468814&results.result-1.shipping-name=Standard+Shipping&results.result-1.shipping-rate.currency=USD&results.result-1.shippable=true&results.result-1.shipping-rate=0.00&results.result-1.total-tax=0.175&results.result-1.total-tax.currency=USD





Using MIVA 5. All updates are installed. Merchant info is put in correctly on both the MIVA side and the Google side.

I am using the UPS module and have the following add-on moduels:

mini-basket (emporium)
best sellers (emporium)
adendum (emporium)
coupon (emporium)
Merchant Moogle
SEO Links (sebenza)

Thanks for your help.

[copperlab]

Okay, Check this out. Here is the testing I have done on this poblem, with what I think to be some weird problems:

At this point I have cleared all my temporary internet files, otherwise the mini-basket will remember my shipping address:

1. Add something to cart.
2. Click calculate shipping on mini-basket. It pops up asking for city, state, and zip code (excatly what it should be doing).
3. I don't put in any information and just click the basket button to try to go through google checkout.
4. I click google checkout button and sign into google and I get the standard+shipping $0 and tax $0 (both should have amounts in them).
5. I click on Edit Order in google checkout and it returns me to my miva store.
6. Now if I click on the mini-basket calculate shipping...It has my information!
7. Now if I click the basket...then google checkout...it has the shipping and tax information in there.

Anyone have any ideas?

[wcw]

In step 3 you put blank info for an address. Shipping modules cannot calculate anything without some address. At this point, with the address blank, the google checkout module should have filled in some address, even if it was a wrong address.

[copperlab]

I do understand that, do you have any ideas why my cart isn't automatically filling in an address?

[wcw]

I don't have any ideas. Miva support?

[dsisaacs]

It seems to me that if Miva would modify the Google Checkout module and the actual button to include an "Enter your zip code" box in the button, Then merchant could do a lookup for the proper shipping methods & costs and pass that info to google checkout.

If the box is empty, this should disable the forwarding to google. For international sales, they could allow a country name or code to be entered.

This information would need to be saved in merchant in the event that the customer returns to the store and makes changes to the order.

AND even though I am not a programmer...I think this could be accomplished in less than a year!

[Vic - WolfPaw Computers]

MIVA has nothing to do with the Google Checkout Module.

It was contracted for by Google, through a well known developer here in the MIVA Community.

Google had VERY specific requirements of the module.

[copperlab]

I went through the list of sites that are using google checkout (there are 5 posts) on another thread on this sub-forum and found two sites that are doing the same thing as mine:

www.madeincalifornia.net (http://www.madeincalifornia.net)
and
http://www.artstampn.com/mm5/merchant.mvc

on my first visit to either site all I did was add an item into my card then go through google checkout...shipping showed up standard+shipping $0. Try it for yourself. I don't why some work and some don't, but it is a problem, and it is not just my site

[dsisaacs]

I just tested my own website, first I cleared my cookies, then added a product to the basket and selected google checkout.

I had recently removed all flat rate options from my shipping configuration and use the USPS module for first class or priority only.

copperlab is right, no shipping charges were added to the completed order.

This is nonsense, I am removing google checkout from my store.

The "well respected module developer" who is responsible for this junk should crawl away and hide.
:mad:

[lbdesign]

This is frightening, and we were about to implement Google Checkout. Does anyone know if we have the standard Miva UPS module or the custom UPS integration with UPS Ground available as an option, will we at least get the UPS ground option in the Google Checkout cart?
thanks,
--Lee

[sebenza]

MIVA has nothing to do with the Google Checkout Module.

MIVA 5 version is distributed by MIVA directly. Google only distributes the v4.

[copperlab]

This is frightening, and we were about to implement Google Checkout. Does anyone know if we have the standard Miva UPS module or the custom UPS integration with UPS Ground available as an option, will we at least get the UPS ground option in the Google Checkout cart?
thanks,
--Lee

I use the regular MIVA included UPS module and do have the problem...I hope that answers your question.

[lbdesign]

MIVA 5 version is distributed by MIVA directly. Google only distributes the v4.

Were both versions written by the same developer or did Miva write the v5 one separately?

I can confirm this bug by visiting a v5 store.

So far, on my v4 store that does have the module, my customers who choose google are getting charged for UPS shipping properly without any bugs. I use the built-in UPS module with Ground as the only option. I don't know if that's a factor or not.

[Vic - WolfPaw Computers]

I was not talking about distribution, I was talking about the actual authoring of the module.

MIVA 5 version is distributed by MIVA directly. Google only distributes the v4.

[lbdesign]

Thanks Vic - So do I understand correctly that any experience I have with using Google Checkout in v4 will have no relation to the coding of the v5 module? There may be problems with the v5 module that do not exist in the v4 module because they were programmed by different persons or groups?

[Vic - WolfPaw Computers]

I was under the impression both modules were developed by the same developer.

If someone else knows differently, I'd be happy to be corrected.

[copperlab]

Just an update. I have an open ticket with MIVA tech support and they are now aware of this thread in the forum. They say they are working on fixing the problem, and when I view the ticket it is classified as a HIGH priority. I don't exactly know what that means...but I will keep you all posted on any updates I get. I also have a workaround that doesn't comply with Google checkout policies, but I am using Google checkout on my site right now. PM me if you would like some help in settng this up. I am not going to post it on the forum because it doesn't comply with their policies.

[bgik77]

Ok! thanks god i found this thread i though I'm the only one with this problem. one of my customer today placed an order for a 124lbs item which in Miva calculate out to be $285.00 for 3 day select to his address but he placed it through Google checkout and it only charge him $99.00. I think this problem is the same problem the creator of this thread describe. Right? if so are there any solution to this problem yet for Miva 4.x compile? I'm using Miva 2.24 / OpenUI; or I have to wait until the next version of the Google Checkout module come out and hope the problem is fixed? unless someone have a work-around solution to the problem?:confused:

[copperlab]

Well here is what MIVA tech support had to say :mad:

Hello David,

Currently when your customers directed to the GoogleCheckout page, GoogleCheckout only waits for 3 seconds to get the shipping information from the MIVA Merchant shopping cart which is hard coded in the google module. Most probably, Google is soon going to launch a module for this issue but I am not sure about any ETA on this.

However, the method which you advised in the last message is really appreciable and useful to recorrect these errors on a temporary basis.

Do let me know if you need further assistance.

Best Regards,
---------------------------------------------

Ben (Bhavesh Chaudhary) | Support Engineer | MIVA Small Business|

Tel: (866) 284-9812 | Fax: (858) 731-4200

MIVA Means Business|www.miva.com | NASDAQ:MIVA


Just an update. I have an open ticket with MIVA tech support and they are now aware of this thread in the forum. They say they are working on fixing the problem, and when I view the ticket it is classified as a HIGH priority. I don't exactly know what that means...but I will keep you all posted on any updates I get. I also have a workaround that doesn't comply with Google checkout policies, but I am using Google checkout on my site right now. PM me if you would like some help in settng this up. I am not going to post it on the forum because it doesn't comply with their policies.

[bgik77]

Well here is what MIVA tech support had to say :mad:

Hello David,

Currently when your customers directed to the GoogleCheckout page, GoogleCheckout only waits for 3 seconds to get the shipping information from the MIVA Merchant shopping cart which is hard coded in the google module. Most probably, Google is soon going to launch a module for this issue but I am not sure about any ETA on this.

However, the method which you advised in the last message is really appreciable and useful to recorrect these errors on a temporary basis.

Do let me know if you need further assistance.

Best Regards,
---------------------------------------------

Ben (Bhavesh Chaudhary) | Support Engineer | MIVA Small Business|

Tel: (866) 284-9812 | Fax: (858) 731-4200

MIVA Means Business|www.miva.com (http://www.miva.com) | NASDAQ:MIVA


Well this is the known 3 sec timeout, which I also hope will be fix soon with the new update.

The problem I mention was more about Google Checkout display incorrectly shipping charges and not using my site's shipping rates.:(

From what I understand this happen when the customer click the Google Checkout button and no shipping info being pass along to Google Checkout, so Google assume the shipping address is the default address which in most case is the Merchant's own address. Can anyone let me know what happen if a customer already login and click on Google Checkout, would Google Checkout assume the shipping address is customer's shipping address instead of the store own address? :D .... just wondering

[wcw]

Already logged in customers should have the correct address passed to google.

[bgik77]

ah thanks, that's good to know.

[JFancett]

This module jsut doesn't seem ready for prime time. We are using Viking Coders UPS integration and the initial shipping cost seems fine, but if we then change the shipping location in google checkout, it doesn't update the shipping cost. Also, I may be doing something wrong, but Google Checkout is not adding the sales tax in our home state. It's a shame, we do enough AdWords to more than cover the fees that would have been associated with using Google Checkout, but we can't deploy this in it's current state.

[Vic - WolfPaw Computers]

I agree.

I think the module was poorly conceived. Don't get me wrong here, I do not fault the developer at all - I think he did the best with what he had to work with.

The problem from the get go was Google refusing to bend at all to work within MIVA's existing API. Google insisted on having control of the customer information and the entire checkout experience - which in its very nature, causes many third party checkout, shipping, and discount modules not to work if Google Checkout is used.


This module jsut doesn't seem ready for prime time. We are using Viking Coders UPS integration and the initial shipping cost seems fine, but if we then change the shipping location in google checkout, it doesn't update the shipping cost. Also, I may be doing something wrong, but Google Checkout is not adding the sales tax in our home state. It's a shame, we do enough AdWords to more than cover the fees that would have been associated with using Google Checkout, but we can't deploy this in it's current state.