[ic] Verisign, double, tripe charges, orders not going through IC

Thu Sep 20 13:31:01 2001

Quoting Ron Phipps (rphipps@reliant-solutions.com):
> Hello,
> 
> We just launched the new CaseEtc.com two days ago and are now using the
> newest PGP and newest Verisign software.  This is to alert all of those
> using the Verisign program to double check their order reports and
> verisign reports for double and triple charges as well as single charges
> where the order was not pushed through IC as valid.
> 
> This problem occurs when the connection to Verisign's server times out.
> The verisign client will return a -12 as the result code.  The Verisign
> IC module interprets this has a failed charge.  However in this
> situation the charge could be valid or it could be invalid.  The reason
> being is that the sales request is making it to Verisign and Verisign is
> processing the card for the amount passed.  However the IC server is not
> receiving the response back from Verisign so the IC server tells the
> user to try again or call in their order.  The user then pushes the
> checkout button again and this whole process can either repeat (possibly
> resulting in 3+ charges), or the order is successful resulting in two
> charges, or the user does not attempt again and walks away (we had this
> on two occasions, luckily they were repeat customers we have since
> contacted).
> 
> This problem did not happen in our test bed however it has happened
> often on the live server up until this morning where all orders were
> either successful the first time or declined for some other reason.
> 
> I'm still contemplating how to fix the Verisign module and I'd like to
> hear form the community on which path I should take.  
> 
> One path is to check the return code of the Verisign client for a '-12'
> in this event immediately send out another verisign transaction with a
> void for the last transaction sent.  Then tell the user something about
> a communications error while processing the card, please try again. This
> would void the transaction IF it went through and allow the user to
> process their order again.

This would seem to be a bug in the Verisign client and have nothing to
do with Interchange. While you might be able to work around it by doing
some sort of return query to verify (i.e. query the txn_id upon
receiving a -12) it is a very bad move on the part of their client. If
something times out and their client can field that, it should never
result in an entered transaction.

Are you positive some portion of the client is not having some
basic system resource problem? What does a -12 error really mean?
12 in the system error numbers is usually ENOMEM; is it possible that
your Interchange user ID is running out of memory on the system due
to quotas or some virtual server memory limitations? 

I wish I could be optimistic about Verisign fixing this, but I bet
that they are spending most of their resources figuring out new ways to
spam their Network Solutions database. ;-\

-- 
Red Hat, Inc., 3005 Nichols Rd., Hamilton, OH  45013
phone +1.513.523.7621      <mheins@redhat.com>

Being against torture ought to be sort of a bipartisan thing.
-- Karl Lehenbauer