Thanks for the complete response Mike...
I guess my main concern is the end-user customer. Having
all their
personal/financial data sitting in someone's home office
would make me
nervous. When a major corporation has a breach (theft), the
notify
their customers and usually offer some kind of identify
theft protection
for a year. But small businesses could never afford that.
Hence they
just cross their fingers that their computer(s) won't get
stolen or
otherwise attacked. Additionally, with products like Stone
Edge, you
either need to setup terminal services or other means to run
the same
executable in the same location. With a web-based approach,
I can run a
business from a beach in Mexico (proven by the way)!
I'm currently working on Fed-Ex. USPS is probably simple
and as soon as
I have someone who requires it, I'll add it. I have a good
architecture
in place so adding different shippers, payment providers,
etc. is not
really a big deal.
Can't see working with Stone Edge as a business partner. I
think our
methods and approach are quite different. Have you looked
at what
they're offering for an enterprise system? Wow, $5K +
hardware and
licenses. They also charge for things like Yahoo real-time
links
($100/year), etc. To me, those are all things that someone
should
expect in the price they pay (they already pay Yahoo in that
case).
MOM, Order Motion, etc. all get customers with their basic
products
because their demos provide all their add-on functionality.
When you
roll up the final price tag, it gets really expensive,
really fast.
Hard to beat $0.25/order, less than a postage stamp for
everything.
My basic premise is that a merchant needs to:
1) receive orders
2) ship product
3) manage inventory (physical or digital)
4) provide info to the business's accounting system
My goal is to do these things well and provide an easy to
use,
consistent and complete view into the merchant's business.
I should be
able to see anything that's happening to me in one (or at
most 2) pages.
I'm geared toward the small-mid sized Ecommerce businesses
but there's
no reason it couldn't scale to a large business either.
Feel free to sign up for the demo. It stays live for 10
days by default
and I can extend that for you if you like.
Tony
http://www.ez-order-m
anager.com
-----Original Message-----
From: google-checkout-api-integration googlegroups.com
[mailto:google-checkout-api-integrationgooglegroups.com] On Behalf Of
mikem
Sent: Wednesday, March 07, 2007 11:40 PM
To: Google Checkout Developers Forum - API Integration
Basics
Subject: [google-checkout-api-integration] Re: Really need
order
export...
Hi Tony,
You beat me to it  Your
website provides exactly the type of service
(decoupled backend order management, integrated with GCO)
that I was
thinking about.
Regarding Stone Edge - it has its pros and cons. It can be
daunting to
setup in the beginning. Although Microsoft Access isn't
exactly an
ideal development platform (it can feel a bit sluggish, for
one thing,
and I don't like Visual Basic, as I'm a Java/C/C++ kind of
guy [I'm a
consultant in my day job]) - it does have some benefits,
such as the
ability to easily write reports. The source is also
exposed, so you can
make modifications if needed. And the underlying database
is, of
course, fully accessible. Because of all this, I've been
able to extend
its functionality to do some things that I needed - like
printing out
USPS COD forms (3816-AS) and firm mailing receipts (3877),
logging COD
payments received by simply scanning the tracking number of
a returned
payment, etc
One big plus is that the folks at Stone Edge _really_
understand the
whole mechanics of selling, and as a result, are able to
apply that
knowledge toward adding useful features.
Having said that, I wouldn't worry about my praise for Stone
Edge above,
because you definitely have the right idea For one
thing, as a
hosted web service, you get (and can send) real-time status
updates, a
definite plus. I haven't tried out your demo yet, but I
will soon.
Additional shipping (label) support (Endicia, FedEx) is
needed, though.
By the way - you know, you could offer the ability to export
to Stone
Edge yourselves. It might seem counter to your business
plans at first,
but in a sense, you both need each other: You don't [yet]
have all the
functionality that Stone Edge offers, and Stone Edge doesn't
offer
direct GCO support (and they can't export order information
directly
from GCO anyway, so a middleware component would be required
as it
stands right now.) This could draw customers that already
use Stone
Edge to use your service. This is actually what brought me
to this
forum to begin with - I was thinking about writing an app to
receive the
notifications from GCO, store those in a database, and then
export the
order information to Stone Edge upon request. But that
seems wasteful,
if Google could just provide an order export API...or if
your website
could export to Stone Edge
Regarding my comment about the XML notifications being
dependent on the
cart: What I meant is that you only have one callback URL
(afaik). If
the shopping cart that you use provides level 2 GCO
integration, then it
needs that URL to point to the cart. You could of course
setup a proxy
that could "tee" the notifications to more than
one destination, but you
get the idea. Moreover, although your hosted service works
well with
synchronous notifications, a desktop application like Stone
Edge does
not - hence the need to "poll" the orders.
In any case, I'm quite excited thinking about the future
possibilities,
especially if Google adds support for non-credit card
payment methods.
I've already spent some time looking at pairing down
VirtueMart to just
a catalog with no backend guts (beyond product
management.) With something like that, plus GCO and your
service, you
have a complete, decoupled system.
Mike
On Mar 7, 2:31 am, "Tony Birnseth" <t...1sit.com> wrote:
> Mike,
>
> Thanks for the excellent post. Did have one question
regarding one of
> your comments....
>
> You Said>>
>
> But since GCO gets all the order details
anyway...an app like
> Stone Edge could just interface directly with GCO,
***and not even
> really care about the shopping cart used***. This would
immediately
> fulfill the requirements of item #3 above. And it would
work for
> everyone - regardless of cart used (or even just
"buy now" buttons.)
>
> The only thing missing is an API to export
orders from GCO
> (preferably in XML format.)
>
> Yes, you can receive order notifications with
full details in
> XML form, but that depends on the shopping cart.
>
> This is exactly what EZ Order Manager does
(www.ez-order-manager.com)
> and is not a MS Access application (I.e.
merchant/customer data is
> secure). It works the same for PayPal and Yahoo Stores
as well.
>
> My question is regarding your statement about the the
XML being
> dependent on the cart? I'm not sure I understand why
you think that
> is the case. All the info comes from GC (collected by
them). The
> only area I could see where the actual Cart comes into
play is if the
> cart did NOT itemize the items in the order and/or the
shipping
> charges (and other charges) were not itemized.
>
<clipped>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the
Google Groups "API Integration Basics" group.
To post to this group, send email to
google-checkout-api-integrationgooglegroups.com
To unsubscribe from this group, send email to
google-checkout-api-integration-unsubscribegooglegroups.com
For more options, visit this group at http://groups.google.com/group/google-checko
ut-api-integration?hl=en
-~----------~----~----~----~------~----~------~--~---
|
