[ic] Authorize.net & fallback to GPG?
Grant
emailgrant at gmail.com
Wed Apr 2 20:37:22 EST 2008
> >>> Has anyone come up with a satisfactory system for giving the user
> >>> info on the result of their pre-auth, but preventing fraudsters
> >>> from testing stolen cards?
> >>>
> >> The Authorize.net configuration will email the GPG'd credit card
> >
> > Should I just write some ITL to email [value mv_credit_card_info] if I
> > don't get a valid response from Authorize.net? That would be simple
> > enough.
>
>
> To the first statement, you can either respond with success or failure as
> usual. The third option is to respond with some bland "thanks for the
> transaction... it is processing and we'll let you know how it is going". You
> don't want to increase your calls to the customer because they made a simple
> honest error, which is usually corrected by receiving and fixing a failure
> response on their part.
>
> If you don't have the manpower for any extra calls, the best is a real
> response and utilize some of Authnet's optional anti fraud packages, or as
> mentioned some attempt limit in IC - say 3 strikes your out.
Do you do this based on IP, session, or both?
> The second & thrid statement means Interchange's Authorizenet's
> configuration, if setup properly, and if GPG is setup properly - even if
> they card is processed by AuthorizeNet, it will additionally get sent GPG'd
> in the report email, and stored in catroot/orders/.
>
> AuthNet and GPG are separate, and if both are setup correctly they will both
> work simultaneously without modification. Simply being setup correctly tells
> them to work.
>
> To decrease your exposure (I guess) you could [if] out the inclusion of the
> encrypted cc block from those above mentioned sources upon a successful
> AuthorizeNet response... i.e., If AuthNet good - supress saving of GPG block
Ok, that makes sense. I think I will go with that [if].
> >> info, you can decide if you are going to just authorize, or capture
> >> each sale . The system I work with, just authorizes transactions,
> >> then posts for settlement upon shipment in the admin UI - this
> >> feature is built in since (5.4?).
> >> The only drawback on authorizations: if the customer attempts to
> >> complete a sale and it takes 2-3 attempts, using incorrect billing
> >> address or zip, and they finally get it right on the 4th try - each
> >> attempt to validate the card locks up the funds for about 24 hours.
> >> So if they try to finish a sale for $100.00 ,4 times, they have
> >> reduced their available credit by $400.00 until the first three
> >> attempts clear - this doesn't happen often, but some people get a
> >> little irate about it.
> >>
> >> I wrote some custom code which limits the number of times that they
> >> can attempt to test a credit card for valid billing address and zip
> >> code, then locks out further attempts, also added CVV test - this
> >> really put a damper on fraudulent activity, but doesn't stop it all.
> >> We capture international cards without authorization, for later
> >> review - we have a really strict policy on international cards on
> >> unknown customers.
> >
> > I like the idea of sending the payment info to Authorize.net without
> > any type of authorization. Which charge type accomplishes that?
>
> There is no sending them data without any authorization. You have to start
> with Authorizing. Authorizing just means you are checking available funds
> and marking them for (likely) capturing later.
Ok, good to know that.
> IIRC there is auth, capture, and Auth+Capture. So you can't sent it without
> any type of authorization. If you need delayed capture, just send it as
> "authorize only", then settle it when you ship it.
Thank you very much Paul.
> Paul Jordan
More information about the interchange-users
mailing list