Announcement

Collapse
No announcement yet.

StoneEdge & Google Checkout

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • StoneEdge & Google Checkout

    Having a problem with StoneEdge downloading orders which Google has not yet completed verification for... here's how I think the process is working right now:

    1. Customer visits our site, chooses Google Checkout and completes order.
    2. Google notifies 3dCart the order has been placed, and 3dCart assigns an order number and places the order into the "Hold" status.
    3. Google reviews the order (for anywhere from a few minutes to many hours) - during this period, the order sits in the "Hold" status.
    4. Eventually, Google decides whether the order is accepted. If the order is accepted, Google alerts 3dCart - the order is moved to the status defined in payment settings (default "New"), and 3dCart returns the order number to Google to store. If Google does not accept the order, 3dCart moves to the order to the "Cancelled" status.

    Our problem is that, while Google is deciding whether to accept the order, and while the order is in the "Hold" status, the order can be downloaded into StoneEdge. Since StoneEdge can't tell whether the order is accepted or not, unless we manually check every order, we could easily end up processing an order that will later be cancelled.

    Is this how it works for everyone else that uses StoneEdge and Google Checkout? Any chance we could get the stonedge.asp script updated to ignore orders in "Hold" status? (but make sure to download them later when they show up in "New" status? heh)

  • #2
    We do not auto approve google checkout orders

    We do not auto approve Google Checkout Orders for this reason. We ask our people to verify in Google Checkout that the order is good to go before the order is approved in OM.

    I like your suggestion and would like to see that implemented.

    Ben

    Comment


    • #3
      Well, I finally tracked this all down and opened a support ticket... hopefully technical support will understand what I'm trying to fix :)

      I also came across a few other issues that are bothersome with Google Checkout and StoneEdge:

      1. No shipping address phone numbers are stored in 3dCart when a customer uses Google Checkout (which means no phone numbers are transferred to StoneEdge either) - the customer enters the phone number, Google shows the phone number if you login to their interface, but 3dCart does not show the phone number anywhere.
      2. Shipping methods are stored differently when Google Checkout is used - if a customer chooses UPS Ground when checking out regularly, the method is stored as "UPS - Ground", but when using Google Checkout, the method is stored as just "Ground" - since we need a matching shipping method in StoneEdge to process the order, this creates a problem (unless we duplicate all of our shipping methods - and it will still be a problem if we offered rates from multiple shippers which have the same service name).

      Hopefully 3dCart will be able to find solutions for these so I don't get annoyed every time someone uses Google Checkout (although I love the free processing!) heh....

      Comment


      • #4
        Originally posted by Jared View Post
        Well, I finally tracked this all down and opened a support ticket... hopefully technical support will understand what I'm trying to fix :)

        I also came across a few other issues that are bothersome with Google Checkout and StoneEdge:

        1. No shipping address phone numbers are stored in 3dCart when a customer uses Google Checkout (which means no phone numbers are transferred to StoneEdge either) - the customer enters the phone number, Google shows the phone number if you login to their interface, but 3dCart does not show the phone number anywhere.
        2. Shipping methods are stored differently when Google Checkout is used - if a customer chooses UPS Ground when checking out regularly, the method is stored as "UPS - Ground", but when using Google Checkout, the method is stored as just "Ground" - since we need a matching shipping method in StoneEdge to process the order, this creates a problem (unless we duplicate all of our shipping methods - and it will still be a problem if we offered rates from multiple shippers which have the same service name).

        Hopefully 3dCart will be able to find solutions for these so I don't get annoyed every time someone uses Google Checkout (although I love the free processing!) heh....
        I hadn't noticed the shipping address phone number one yet, but did notice the shipping name thing. I thought it was something I had misconfigured and couldn't find again in 3d or Google. :)

        I finally just made an approval rule that changes it to my SE "UPS - Ground" as a workaround.

        DaveW

        Comment


        • #5
          Here's the current status on all three:

          Original problem: resolvable, but requires a change to the export script. You can ask technical support to do it (you'll probably have to pay), or you can update the script yourself... just need to add "and orderstatus<>6" to the SQL queries that retrieve orders to download.
          1. There's an advanced option in the Google Checkout interface (under Integration -> Advanced Options) that lets you turn on exporting the shipping phone number - once that checkbox is checked, the phone number comes in perfectly.
          2. Not an easy change for 3dCart to fix, so the easiest solution is, as Dave mentioned, just creating an approval rule to switch "Ground" to "UPS - Ground", etc. (Might not work if you have both FedEx and UPS Ground activated on your store, but otherwise should work fine.)

          Which means I'm now 100% totally happy with the StoneEdge/Google Checkout stuff, and I don't have to watch it so carefully... only problem left is that, based on the queries being used if you fix the main problem I listed above, an order might not be downloaded if:

          1. Customer places order before midnight (lets say at 11:55pm on 1/1)
          2. Google Checkout starts verifying the order, but takes an exceptionally long time.
          3. Employee imports orders in the morning (lets say 7am on 1/2)
          4. Google Checkout approves the order after 7am

          In this case, StoneEdge would already have orders from 1/2, so it would not ask for orders from the previous day. The order also would have an older order number, so it would not get caught there either.... obviously, this is a very unlikely scenario, but I wanted to mention it anyway... I will just log into Google Checkout infrequently and make sure all orders are charged/shipped or cancelled, then archive them.

          Comment


          • #6
            I am a new SEOM customer and we are still in the setup phase. After reading this post I wanted to avoid the pitfalls everyone else has already encountered with Google Checkout.

            I tried to update the 3dcart stoneedge.asp script but I get a permission denied error when I try to modify the file (via FTP). When I asked 3dcart support to give me permissions for that file I received the following answer:

            "Unfortunately this is a global script that applies to all our clients. And for most of the clients Google Checkout orders are charged automatically.

            The problem with the download is that SEOM requests orders by last Invoice Number, so if you skip an order for being in the ON HOLD status, and new order numbers are downloaded from NEW, then the orders that were skipped would never be downloaded.

            We're in discussion with Stone Edge regarding an alternative download method vs the current Invoice Number / Order Date, where perhaps ALL orders in the NEW status are always downloaded, but we need to make sure that this would apply to all merchants and that no duplicated orders are going to be downloaded even if the orders still remain in the NEW status."


            Has anyone else had any trouble getting SEOM to download only authorized/charged orders and not on hold orders (google running checks)?

            thanks
            Onfam

            Comment

            Working...
            X