Google Checkout and CBS- Shipping SuperMod Module Problem

[Greg Maranto]

We are trying to implement Google Checkout.

We are using the CBS- Shipping SuperMod because we have products that ship by UPS, Motor Freight or both.

Our normal (MIVA) checkout process is working normally with only the correct shipping options showing up (based on Ship To state)

For Motor Freight, We use weight based tables that are selected by Ship To state. ALL Motor Freight weight based tables are showing up as choices in Google Checkout, Not just the two Motor Freight choices that should show up based on Ship To state.

What is the workaround?

Thanks,
Greg S. Maranto

[chucklasker]

Same problem on any site with Shipping Supermod and Google Checkout. Sounds like it's a timing issue - Shipping SuperMod takes too long to respond to Google Checkout with the options, so Google Checkout shows them all. Google says it's a Miva problem that Miva has to fix. I haven't heard of a solution.

[wcw]

The problem is likely that the supermod does not know the ship to state when you are transported to google for checkout. Therefore, it can't provide the shipping options correctly. The google API requires that you go to them before the ship to location is determined.

[chucklasker]

Interesting. That makes sense. Then, when someone enters their address in Google Checkout, it tries to get the options from Miva, but only gives Miva a short time to respond.

Would it be possible to have the Google Checkout button have a small form for state/country before submitting? I know there's a whole API going on, so maybe someone can come up with a modular fix. It's frustrating having no control at all without a module.

[wcw]

It has nothing to do with the time to respond. You are seeing all the methods from supermod because that is what it shows when not presented with the correct ship to address. At the time you go to google, the address is not known, yet google expects the shipping modules to provide/display the eligible methods. It cannot because the ship to location is not known on that initial transfer to google. It is an API conflict that cannot be fixed unless google changes their API to suit MIVA Merchant. Fat chance.

[chucklasker]

oh, okay - it was explained differently to me, that Google sends the shipping info back to Miva Merchant for shipping options. Guess not. How crazy.

Thanks, Bill.

[wcw]

Initially merchant querries all the shipping modules for the methods they are going to provide. It uses the store's address for "ship to" since it does not yet know the customer's address. That produces erroneous methods from shipping modules that base the available methods upon the ship to address. Then at google the customer enters their address and selects a method from the erroneous list of methods.

[sebenza]

To clarify here... All shipping methods are sent originally to Google when the Google Checkout button is clicked. Once the user logs into their Google Checkout account another request is sent back to Miva to double check the methods and get the actual rates. Any invalid methods are then removed.

The problem with the SuperMod... it should work fine in any v4 store. It will not work in a v5 store since the Shipping SuperMod no longer hijacks the shipping method call and it simply just filters the methods by way of component extension. So in short... the v5 was not created the same way as the v4... not sure why.

[wcw]

Scott,

Are you saying you fixed the Google module so it resubmits to get the list of eligible methods so the customer gets a new list of shipping methods after they log in? Does that mean my zone modules will now work with the updated Google module? I have no way to test as I could never get the Google checkout module to work in my store.

[sebenza]

Sorry... I mis-read something. The way that Miva coded the module is that it cross checks the methods and gets rid of any that are invalid. It will not create new methods based on new shipping information. This is not a module issue, but rather a Google Checkout issue. Google Checkout will only accept the methods originally sent... which is backwards if you ask me.

[Greg Maranto]

Scott,

Is anyone with Miva Merchant or Sebenza discussing this with Google?

I am sure we are not the only company affected by this>

Thanks To All Who Have Responded!

[sebenza]

Google knows about this. A simple fix by Google that would pass the shipping methods post login would be ideal... but for some reason they want the shipping methods before the address is known.

[chucklasker]

Google, like FireFox and Apple, thinks it knows best and all others must follow their lead. So, I guess we're all supposed to have set shipping fees. Or maybe they want everyone to be free shipping??

Chuck

[Superior1]

I am not sure if I use the shipping super mod or not? But is there any way a customer can let Miva (or ultimately google) know that they are international before sending the form data to google? This might be something related to a pre-checkout page but from my understanding google doesn't want any internediate pages between any of their buttons and their checkout cart?
It seems to be a difficult workaround to have both domestic and shipping. I have heard complaints that some HTML recoding has been done but it either offers free shipping to international or else no shipping at all at least for carrier calculated.

I know some have been implementing an international shipping product on their store so that customers can purchase international shipping as a product, which seems it would work but is a big inconvience to both parties. And expecting your customers to purchase the proper amount of shipping on a variety of weights is also nothing you as a merchant needs your customer deciding.

Any solutions for this?