Re: [ic] Credit Card Processing Times Out

[Jon <suppressed>]

>
> >>>>>
> >>>>>- Add the following line to your catalog.cfg:
> >>>>>
> >>>>>Variable        MV_PAYMENT_MODE ICS
> >>>>>
> >>>>>- Add the following lines down in your Route section of your catalog.cfg
> >>>>>(I added it after itransact)
> >>>>>
> >>>>>Route   ICS     server_host     ics2.ic3.com
> >>>>>Route   ICS     server_port     80
> >>>>>Route   ICS     path            /opt/CyberSource/SDK
> >>>>>Route   ICS     merchant_id     v38417948
> >>>>>Route   ICS     apps            ics_auth,ics_auth_reversal,ics_bill,ics_credit
> >>>>>Route   ICS     timeout         20
> >>>>
> >>>>
> >>>>How is this timeout parameter used in the Payment processing ?
> >>>>Does anyone know if this is supported in the generic Payment module
> >>>>or just in specific payment modules (e.g. BoA) ?
> >>>>
> >>>>In general is there a time limit the Payment process waits before declaring
> >>>>a failure and can this be modified via a parameter for any or only specific
> >>>>payment module ?  I'm most interested in ECHO.
> >>>>
> >>>>Thank you,
> >>>>Jon
> >>>
> >>>Jon,
> >>>
> >>>If I'm understanding correctly what you want to do you can work this out
> >>>by changing the traffic settings inside Interchange from Low to rpc in
> >>>the interchange.cfg file.
> >>>
> >>
> >>    Appreciate the response Mark.  I tried RPC mode and it caused major problems.
> >>Kind of hard to explain.  It appeared as if the multiple IC processes (daemons) were
> >>
> >>exchanging data with each other. For example the dollar amount from one order would
> >>be
> >>billed against another customer's credit card. In other words customer 1's order
> >>would
> >>complete and then customer 2 would complete their order but the dollar amount
> >>charged
> >>would be from customer 1's order. I had no idea where to begin debugging that one.
> >>
> >>Jon
> >>
> >
> >
> >    The more I think about this and poke around at the code and logs I think
> > this is just a matter of the CC process taking to long and IC giving up and
> > declaring it a failure. Looking at log_transaction, and what I see in the log when
> > the process dies, the code/string that should contain details from the GW about the
> > reason for rejection it is instead just 0.  When there is a bona fide CC failure
> > the entire string of information from the CC GW is written to CART/logs/log.
> > But when it simply times out the the reason string is just '0'   Clearly IC isn't
> > waiting long enough.  I'm using the high TRAFFIC mode with a PIDCheck 120
> > if that would make a difference.  Otherwise anyone know if there is a global
> > or catalog configuration value that would tell IC to wait longer for the CC
> > server to respond ?  I can debug if necessary but some guidance on where
> > to begin would be greatly appreciated.
> >
> > Thank you.
> >
> > Jon
>
> At this point before you get any deeper into it, it might be a good idea
> to call the GW and tell them what you're seeing. They might be able to
> offer some information as to what exactly is going on that would help.
>
>

   Yes that is what I plan to do though I have already emailed them with
no response so far. What I was hoping to get a better understanding of
before I get someone on the phone is the IC side if, for example, I'm
able tweak a parameter somewhere to force IC to pause a little longer
before declaring failure. I'm sure once I get a technical person on the
phone this will come up in conversation.

  Can anyone give some insight into IC's apparent time out scenario ?

Jon



_______________________________________________
interchange-users mailing list
suppressed
http://www.icdevgroup.org/mailman/listinfo/interchange-users