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

Ron Phipps interchange-users@interchange.redhat.com
Thu Sep 20 14:30:02 2001


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

I definitely agree that this seems like a bug in the Verisign client and
I have contacted their support staff to see which steps to take.  It
appears that they have taken steps to know when this occurs since we
received the automated email that said to the effect "a response was
never received and these transactions will not be fulfilled until you
contact us".  Although it would be better if the transaction was
automatically voided or never even accepted if the client does not
receive the response, we then wouldn't have this problem.

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

It could be a system resource problem, however it should not be due to
any user restrictions.  The IC server is not running on a virtual server
and it is only running this one catalog with each user having full
access to available memory and disk space.  The server is a dual 450
with 256mb ram.  We will be adding another 256mb ram tonight just in
case this is the issue.

A -12 based on Verisign's response codes is equal: Timeout waiting for
response.  This would be in line with Verisign sending us an email
saying the transaction timed out.

I increased the timeout value from 10 to 30 last night and after doing
so received 3-4 more orders that had this same problem.  However
starting this morning all orders have gone through without this problem.
I'm keeping a close eye on it to make sure it does not continue to
happen.

Here is what I see in the icdebug when a transaction times out and when
a transaction completes.  Notice that there is no result string received
the first time.

Timed out transaction:

Vend::Payment:debug: signio query: {
  'TRXTYPE' => 'S',
  'TENDER' => 'C',
  'AMT' => '22.69',
  'ZIP' => 97520,
  'STREET' => '500 A Road',
  'SHIPTOZIP' => 97520,
  'ACCT' => '4719xxxxxxxxxxxx',
  'EXPDATE' => '0104',
  'PWD' => 'xxx',
  'PARTNER' => 'Verisign',
  'VENDOR' => undef,
  'ORIGID' => '01091921534730830',
  'USER' => 'xxx'
}

Vend::Payment:debug: signio call: /usr/local/ic/lib/pfpro
payflow.verisign.com 443
"TRXTYPE=S&TENDER=C&AMT=22.69&ZIP=97520&STREET=500 A
Road&SHIPTOZIP=97520&ACCT=4719xxxxxxxxxxxx
&EXPDATE=0104&PWD=xxx&PARTNER=Verisign&VENDOR=&ORIGID=01091921534730830&
USER=xxx" 10 > /home/store/store/tmp/signio.01091921534730830
Vend::Payment:debug: signio decline=12 result: [no result string]
Vend::Payment:debug: signio decline=0 result: {
  'ICSTATUS' => 'failed',
  'MStatus' => 'failed',
  'pop.status' => 'failed',
  'pop.error-message' => 'Charge error:  Reason: . Please call in your
order or try again.',
  'MErrMsg' => 'Charge error:  Reason: . Please call in your order or
try again.'
}

Complete transaction seconds later with same information:

Vend::Payment:debug: signio query: {
  'TRXTYPE' => 'S',
  'TENDER' => 'C',
  'AMT' => '22.69',
  'ZIP' => 97520,
  'STREET' => '500 A Road',
  'SHIPTOZIP' => 97520,
  'ACCT' => '4719xxxxxxxxxxxx',
  'EXPDATE' => '0104',
  'PWD' => 'xxx',
  'PARTNER' => 'Verisign',
  'VENDOR' => undef,
  'ORIGID' => '01091921534730830',
  'USER' => 'xxx'
}

Vend::Payment:debug: signio call: /usr/local/ic/lib/pfpro
payflow.verisign.com 443
"TRXTYPE=S&TENDER=C&AMT=22.69&ZIP=97520&STREET=500 A
Road&SHIPTOZIP=97520&ACCT=4719xxxxxxxxxxxx
&EXPDATE=0104&PWD=xxx&PARTNER=Verisign&VENDOR=&ORIGID=01091921534730830&
USER=xxx" 10 > /home/store/store/tmp/signio.01091921534730830
Vend::Payment:debug: signio decline=0 result:
RESULT=0&PNREF=xxx&RESPMSG=Approved&AUTHCODE=018564&AVSADDR=N&AVSZIP=Y

Vend::Payment:debug: signio decline=0 result: {
  'ICSTATUS' => 'success',
  'MStatus' => 'success',
  'pop.status' => 'success',
  'pop.avs_code' => 'Y
',
  'pop.avs_addr' => 'N',
  'RESPMSG' => 'Approved',
  'pop.order-id' => 'xxx',
  'AVSADDR' => 'N',
  'order-id' => 'VPNA03831778',
  'pop.auth-code' => 'xxx',
  'pop.avs_zip' => 'Y
',
  'PNREF' => 'xxxx',
  'AUTHCODE' => 'xxx',
  'AVSZIP' => 'Y
',
  'RESULT' => '0'
}


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

LOL, I was surprised you responded based on the company involved.
You'll probably receive 100 emails today from them for that one comment.
;)

-Ron