Point being that GC is not designed for (nor supports) being
used solely
as a payment processor. Their whole goal is to provide the
buyer with a
"one stop" payment location where they can track
their online payments
to a variety of merchants.
The API is intended to provide the merchant "post
sales" information
about the customer so it can be incorporated into their
back-end
processing for accounting, shipping and other back-end
support.
I fear that you may be misunderstanding GC's capabilities
and intent.
This isn't to say that I don't agree with your points, but
rather that
what you want to do is neither supported nor approved by
GC.
Tony
www.ez-order-manager.com
-----Original Message-----
From: google-checkout-api-integration googlegroups.com
[mailto:google-checkout-api-integrationgooglegroups.com] On Behalf Of
drewd
Sent: Friday, March 09, 2007 10:40 AM
To: Google Checkout Developers Forum - API Integration
Basics
Subject: [google-checkout-api-integration] Re: Risk
Information
Notifications
Then why is it that google provides you with a PHP API, that
does
exactly that. And I am not actually using a GC button on my
website. I
would just use the API. I guess that would only apply to
people that are
using GC but if you are only using google to process
payments through
their API, then you can do all of the authentication on the
backend,
which is where it should be done anyway.
On Mar 9, 12:33 pm, "Tony Birnseth" <t...1sit.com> wrote:
> In that scenario, GC will disable your account since
you are
> authenticating the user before presenting the GC
button. But....
>
> Tony
>
> www.ez-order-manager.com
>
>
>
> -----Original Message-----
> From: google-checkout-api-integrationgooglegroups.com
>
> [mailto:google-checkout-api-integrationgooglegroups.com] On Behalf Of
> drewd
> Sent: Friday, March 09, 2007 9:27 AM
> To: Google Checkout Developers Forum - API Integration
Basics
> Subject: [google-checkout-api-integration] Re: Risk
Information
> Notifications
>
> Actually, the best way would be to create your own
order processing
> system and integrate with google. Then you can store
the entire 16
> diget cc number in your db, encrypted ofcourse. Then
run a check
> against it before you send the order to google. You can
even go as far
> as creating an authentication system, where inorder for
your customer
> to even be able to purchase they must first
authenticate. Then just
> use Sessions over SSL to track what the customer is
doing. Or not even
> allow them to create a 2nd account if it doesnt pass
your checks. This
> is prognamtically intesive, but I use a similar system.
It is
> impossible for a customer to do anything that would
crash or
> compromise my system in any way, nor could they commit
any kind of
> fraud. As an extra security step if a customers IP
address changes
> from the one the registered with they must
re-authenciate their
> account to be able to login.
>
> On Mar 8, 7:11 pm, "kquad"
<warcraftl...gmail.com> wrote:
> > I am curious if I change the way orders are
processed from
> > authorize and charge to just authorize, would I be
able to receive
> > the 4 digit credit card info and IP of the person
making the charge
> > to check it against our IP-blacklist before
charging the persons
card.
> > If this is not an option, would I be able to have
the 4 digit
> > credit card info and IP address sent as risk
information when the
> > states are CANCELLED and CANCELLED_BY_GOOGLE to
help build our
IP-blacklist.
>
> > Thank you for any help or suggestions.
>
> > Eric- Hide quoted text -
>
> - Show quoted text -
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
|
