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

[Ed LaFrance]

At 09:32 AM 09/20/2001 -0700, you wrote:
>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

They never do! :-/

>  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.
>
>The second path would be to check the return code for a '-12' and in
>this event allow the order to go through, but flag it on the email sent
>to the shop owner that we did not receive a response from Verisign.
>This would then not alert the user that there was a problem and allow
>the order to go through.  But the shop owner would then have to verify
>the funds were received.  If they were not received then the owner would
>have to rerun the card.
>
>I'm open to any other suggestions/solutions.  I'm not sure which path to
>take, I just know that it needs to be fixed soon because this looks like
>the only time a charge can get through and the order not be accepted by
>IC.

Well, that bites!  I think your latter option (allowing the order to go 
through an flagging the store notification that a communications problem 
occurred) is the better idea an should be the standard response to such a 
situation (perhaps you could share the modifications). If communications 
failures are occurring between your server and Verisign's, retrying will 
probably just exacerbate the problem overall.  Of course that is a 
short-term solution; getting to the bottom of these timeouts is what is 
really required.  Since Verisign now owns CyberCash, this would be of 
general concern, I think.

Did Verisign have anything to say about this?  Nimda worm?

- Ed L.




===============================================================
New Media E.M.S.               Software Solutions for Business
463 Main St., Suite D          eCommerce | Consulting | Hosting
Placerville, CA  95667         edl@newmediaems.com
(530) 622-9421                 http://www.newmediaems.com
(866) 519-4680 Toll-Free       (530) 622-9426 Fax
===============================================================