[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