[ic] Authorize.net & fallback to GPG?

[Paul Jordan]

>>> 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.

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


>> 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.

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.

HTH

Paul Jordan
  Gish Network
  For Print, Web, and Life
  t.626.285.7609 / f.866.401.2657
  www.gishnetwork.com