[Date Prev][Date Next][Thread Prev][Thread Next][Interchange by date
][Interchange by thread
]
Re: [ic] Verisign, double, tripe charges, orders not going through IC
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
===============================================================
_______________________________________________
interchange-users mailing list
interchange-users@interchange.redhat.com
http://interchange.redhat.com/mailman/listinfo/interchange-users