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

[Ron Phipps]

> From: interchange-users-admin@interchange.redhat.com
[mailto:interchange-
> users-admin@interchange.redhat.com] On Behalf Of 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! :-/

So true, same thing happened last time we launched the site.  Had CC
errors that only happened on the live side :(


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

Yeah it does bite.  I'm glad we saw that this was happening though.  It
seems it could happen at any time and we would not be alerted to it
until we audited our reports.

I imagine this will be of general concern "IF" Verisign plans to phase
out the cybercash module.  We saw that certain users would attempt 2-3
times before the order goes through, causing double charges.  I'm still
torn on which route to go, in the first case the customer is alerted to
the problem right away and they can retry.  In the second case the user
is not alerted until the shop owner contacts them, although they may not
be contacted in all cases.  The second path however requires manual
steps to fulfill the order, whereas the 1st path puts it on the user to
try again.  Hrmm.....

I will definitely share any modifications that I end up performing on
the Verisign IC module to get around this problem until VSign can find a
permanent solution.

> 
> Did Verisign have anything to say about this?  Nimda worm?
> 
> - Ed L.

I sent an email off to them last night after we received the warning
from their system.  I will share their response.

Thanks!
-Ron