To remain compliant with GC's policies I would suggest that
you create
the account for the customer AFTER you receive the
<new-order-notification>. You will then know the
customer has completed
the process even if they haven't completely paid for it yet.
Your
back-end processing would create the account based on the
info returned
in the <new-order-notification>. But I'd leave a
status of
'not-activated' or something until you receive the
'charged'
<financial-state-change> notification.
If you run a subscription type service or another type where
there's a
recurring charge, you can do what I do:
1) Send the customer an email with a link to a secure
portion of your
site and with a key to their current invoice info.
2) Show them their invoice or other charge info and present
them with a
GC button.
This way you stay in compliance by not requiring the user
(customer) to
login before being presented the GC button and you allow
them to pay.
Security is not a big issue here because you don't really
care who pays,
as long as it's paid. But if you're concerned about who
might see the
charges, you can add some additional authentication to the
link itself.
There's also a way to put the GC button directly in the
email but I
haven't done that yet but think it would be a good
approach.
I present Accounts Receivable address for those who want to
pay by
check, a GC button and a PayPal button. This all leaves me
in
compliance but allows my customers to pay their monthly bill
with as
much ease as possible. It also gives them visibility and
confirmation
of the charges rather than just dinging their credit cards
for a
variable amount each month.
Tony
www.ez-order-manager.com
-----Original Message-----
From: google-checkout-api-integration googlegroups.com
[mailto:google-checkout-api-integrationgooglegroups.com] On Behalf Of
kquad
Sent: Friday, March 09, 2007 11:59 AM
To: Google Checkout Developers Forum - API Integration
Basics
Subject: [google-checkout-api-integration] Re: Risk
Information
Notifications
Thank you for the excellent ideas. As I do not wish to be
disabled by
GC, I have a couple questions on implementing some of drewds
ideas.
I do not wish to take credit card information if that will
violate the
Terms of GC, but having the customer make an account in
order to
complete the purchase is a great idea. Since I use OSC it
should be easy
by using one of the hide contributions. The problem I see is
repetition
in having to create two accounts in order to place an order.
Is there a
way to pass certain account information; e.g. Name, Address,
Phone #,
etc., from OSC into GC's account creation, when the person
is logged
onto my site?
Thank you again for the help.
Eric
On Mar 9, 9:33 am, "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
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
|
