Problems with Payflow Pro object (PFProCOMContro l.PFProCOMContr ol.1)

[Brian]

Anyone worked with Verisign's Payflow Pro object in ASP? We've had it
up and running for weeks without a problem and recently we've started
to get some undesirable behavior: at the point where the component
sends the transaction data, about 1 in 4 times it will go through, but
otherwise it will sit and spin until the script or the browser session
times out. may or may not be related to a server maintenance change.

I'm not a server admin guy, so I don't know specifically what to look
for, but can anyone tell me what I should ask our server admin guy to
look for? Could there be something with COM threading or other issues
where multiple instances of this object are being run? Is there a
place on the server where a person can look and see what's going on
with this object?

Here's the code with some info removed... I've marked where it usually
locks or spins:

*************** ************

Set client = Server.CreateOb ject("PFProCOMC ontrol.PFProCOM Control.1")

'Transaction through Verisign
parmList = "TRXTYPE=S&TEND ER=C&PARTNER=Ve riSign&VENDOR=X XXXXXX&USER=XXX XXXX&PWD=XXXXXX X&ACCT=41111111 11111111&EXPDAT E=0405&AMT=0.01 "

Ctx1 = client.CreateCo ntext("test-payflow.verisig n.com", 443, 30, "",
0, "", "")

'this next line is what locks up the object or goes into a loop
curString = client.SubmitTr ansaction(Ctx1, parmList, Len(parmList))

client.DestroyC ontext (Ctx1)

set Ctx1 = nothing
set client = nothing

*************** ************

Thanks for your help.

[Don Grover]

Hi Brian

I put several thousand transactions a day and its never missed a beat, so I
know the coontrol is working well.
I would log all the entered details to either a database or text file along
with start time, end time in seconds, date etc.
Also would log the return values from Verisign.

When you go into the control center of verisign do the failed transaction
show up ?
Has it an error number.

It sounds like a time out to verisign, I would check connection over a
number of hours to verisign and see if connection is being dropped or timing
out.

Regards
Don
dgroverATassoft .com.au
"Brian" <al************ *@hotmail.com> wrote in message
news:ba******** *************** ***@posting.goo gle.com...

Anyone worked with Verisign's Payflow Pro object in ASP? We've had it
up and running for weeks without a problem and recently we've started
to get some undesirable behavior: at the point where the component
sends the transaction data, about 1 in 4 times it will go through, but
otherwise it will sit and spin until the script or the browser session
times out. may or may not be related to a server maintenance change.

I'm not a server admin guy, so I don't know specifically what to look
for, but can anyone tell me what I should ask our server admin guy to
look for? Could there be something with COM threading or other issues
where multiple instances of this object are being run? Is there a
place on the server where a person can look and see what's going on
with this object?

Here's the code with some info removed... I've marked where it usually
locks or spins:

*************** ************

Set client = Server.CreateOb ject("PFProCOMC ontrol.PFProCOM Control.1")

'Transaction through Verisign
parmList = "TRXTYPE=S&TEND ER=C&PARTNER=Ve riSign&VENDOR=X XXXXXX&USER=XXX XXXX&PWD=XXXXXX X
&ACCT=411111111 1111111&EXPDATE =0405&AMT=0.01"
Ctx1 = client.CreateCo ntext("test-payflow.verisig n.com", 443, 30, "",
0, "", "")

'this next line is what locks up the object or goes into a loop
curString = client.SubmitTr ansaction(Ctx1, parmList, Len(parmList))

client.DestroyC ontext (Ctx1)

set Ctx1 = nothing
set client = nothing

*************** ************

Thanks for your help.

[bryan]

Hi Brian,

I'm having the same problem and it's KILLING ME.

Were you ever able to come across a solution? Any help or ideas you
could provide would be MUCH APPRECIATED.

Thanks in advance.

- Bryan

Brian wrote:

Anyone worked with Verisign's Payflow Pro object in ASP? We've had it up and running for weeks without a problem and recently we've started
to get some undesirable behavior: at the point where the component
sends the transaction data, about 1 in 4 times it will go through, but otherwise it will sit and spin until the script or the browser session times out. may or may not be related to a server maintenance change.

I'm not a server admin guy, so I don't know specifically what to look
for, but can anyone tell me what I should ask our server admin guy to
look for? Could there be something with COM threading or other issues where multiple instances of this object are being run? Is there a
place on the server where a person can look and see what's going on
with this object?

Here's the code with some info removed... I've marked where it usually locks or spins:

*************** ************

Set client = Server.CreateOb ject("PFProCOMC ontrol.PFProCOM Control.1")

'Transaction through Verisign
parmList = "TRXTYPE=S&TEND ER=C&PARTNER=Ve riSign&VENDOR=X XXXXXX&USER=XXX XXXX&PWD=XXXXXX X&ACCT=41111111 11111111&EXPDAT E=0405&AMT=0.01 "
Ctx1 = client.CreateCo ntext("test-payflow.verisig n.com", 443, 30, "",
0, "", "")

'this next line is what locks up the object or goes into a loop
curString = client.SubmitTr ansaction(Ctx1, parmList, Len(parmList))

client.DestroyC ontext (Ctx1)

set Ctx1 = nothing
set client = nothing

*************** ************

Thanks for your help.

[Don Grover]

<br***@chameleo n-systems.com> wrote in message
news:11******** **************@ c13g2000cwb.goo glegroups.com.. .

Hi Brian,

I'm having the same problem and it's KILLING ME.

Were you ever able to come across a solution? Any help or ideas you
could provide would be MUCH APPRECIATED.

Thanks in advance.

- Bryan

Brian wrote:

Anyone worked with Verisign's Payflow Pro object in ASP? We've had

it

up and running for weeks without a problem and recently we've started
to get some undesirable behavior: at the point where the component
sends the transaction data, about 1 in 4 times it will go through,

but

otherwise it will sit and spin until the script or the browser

session

times out. may or may not be related to a server maintenance change.

I'm not a server admin guy, so I don't know specifically what to look
for, but can anyone tell me what I should ask our server admin guy to
look for? Could there be something with COM threading or other

issues

where multiple instances of this object are being run? Is there a
place on the server where a person can look and see what's going on
with this object?

Here's the code with some info removed... I've marked where it

usually

locks or spins:

*************** ************

Set client = Server.CreateOb ject("PFProCOMC ontrol.PFProCOM Control.1")

'Transaction through Verisign
parmList =

"TRXTYPE=S&TEND ER=C&PARTNER=Ve riSign&VENDOR=X XXXXXX&USER=XXX XXXX&PWD=XXXXXX X&ACCT=41111111 11111111&EXPDAT E=0405&AMT=0.01 "

Ctx1 = client.CreateCo ntext("test-payflow.verisig n.com", 443, 30, "",
0, "", "")

'this next line is what locks up the object or goes into a loop
curString = client.SubmitTr ansaction(Ctx1, parmList, Len(parmList))

client.DestroyC ontext (Ctx1)

set Ctx1 = nothing
set client = nothing

*************** ************

Thanks for your help.

Write a log file of parmList, Len(parmList), and check it
You will more than likely find an ilegal character or missing value.
I move 2-300 at one go through Verisign and do some fairly extensive
checking before hand, its usually something in address or order/freight
details.
Regards
Don Grover

[albinocrocodile]

I would up logging any and all information I was sending through the
object. Each time a transaction is run, I get an email before and
after to insure that I know when something hasn't gone through. I also
made a few small changes to the way I was sending transaction
information, making sure all expiration dates are correct and making
sure all objects were opened and closed appropriately (trying not to
double them up or nest transactions). It has been running fine now for
about 3-4 months. I'm pretty sure it's good now.

Unfortunately, I can't say what the one thing was that resolved this.
It was frustrating because we couldn't identify the problem, the object
would just stall, and intermittently at that. I'm sure you're seeing
how frustrating that can be. As the other comment in this thread
suggests, you should just go through the code everywhere the
transactions are being made and double check everything, make sure it's
all clean, get it logging if possible, etc. I was pretty sure that the
code wasn't the problem when I was dealing with this, but after
revising a few areas and cleaning it up a bit, it seems to have
resolved the issue (unless the server admin changed something that was
creating the problem).

Hope this helps.
Brian

br***@chameleon-systems.com wrote:

Hi Brian,

I'm having the same problem and it's KILLING ME.

Were you ever able to come across a solution? Any help or ideas you
could provide would be MUCH APPRECIATED.

Thanks in advance.

- Bryan

Brian wrote:

Anyone worked with Verisign's Payflow Pro object in ASP? We've had

it

up and running for weeks without a problem and recently we've started to get some undesirable behavior: at the point where the component
sends the transaction data, about 1 in 4 times it will go through,

but

otherwise it will sit and spin until the script or the browser

session

times out. may or may not be related to a server maintenance change.
I'm not a server admin guy, so I don't know specifically what to look for, but can anyone tell me what I should ask our server admin guy to look for? Could there be something with COM threading or other

issues

where multiple instances of this object are being run? Is there a
place on the server where a person can look and see what's going on
with this object?

Here's the code with some info removed... I've marked where it

usually

locks or spins:

*************** ************

Set client = Server.CreateOb ject("PFProCOMC ontrol.PFProCOM Control.1")
'Transaction through Verisign
parmList =

"TRXTYPE=S&TEND ER=C&PARTNER=Ve riSign&VENDOR=X XXXXXX&USER=XXX XXXX&PWD=XXXXXX X&ACCT=41111111 11111111&EXPDAT E=0405&AMT=0.01 "

Ctx1 = client.CreateCo ntext("test-payflow.verisig n.com", 443, 30, "", 0, "", "")

'this next line is what locks up the object or goes into a loop
curString = client.SubmitTr ansaction(Ctx1, parmList, Len(parmList))

client.DestroyC ontext (Ctx1)

set Ctx1 = nothing
set client = nothing

*************** ************

Thanks for your help.

[bryan]

Don -- Thanks for the reply!

Are you saying that you've seen this error happen just because there
was something off in the paramList??? I would hope it wouldn't choke
that hard on a bad string.

I would REALLY like to hear if you've seen this happen because of a bad
parmList.

I'll take you advice though and start logging. I'm logging the data we
used to create the parmList after the crash, but not the actual
parmList itself. I'll start doing that and see if I get something
unexpected.

Unfortunately, I may have to suffer through another crash to see what's
going on...

- Bryan

Don Grover wrote:

Write a log file of parmList, Len(parmList), and check it
You will more than likely find an ilegal character or missing value.
I move 2-300 at one go through Verisign and do some fairly extensive
checking before hand, its usually something in address or order/freight details.
Regards
Don Grover

[Don Grover]

Use on Error Resume Next
Log all details
Log the return value if any
Pickup the error number and halt script.
I send my self an email if other than 0 is returned, allong with the
parameter list in a string so I get all data.
The delimiting and data seperators are critical when pasing data to the
object,.

If you send me your email, I can send you a script what I use to talk to ver
in an automated fashion.
It may help with virifcation
Don
dg*****@assoft. com.au
<br***@chameleo n-systems.com> wrote in message
news:11******** **************@ c13g2000cwb.goo glegroups.com.. .

Don -- Thanks for the reply!

Are you saying that you've seen this error happen just because there
was something off in the paramList??? I would hope it wouldn't choke
that hard on a bad string.

I would REALLY like to hear if you've seen this happen because of a bad
parmList.

I'll take you advice though and start logging. I'm logging the data we
used to create the parmList after the crash, but not the actual
parmList itself. I'll start doing that and see if I get something
unexpected.

Unfortunately, I may have to suffer through another crash to see what's
going on...

- Bryan

Don Grover wrote:

Write a log file of parmList, Len(parmList), and check it
You will more than likely find an ilegal character or missing value.
I move 2-300 at one go through Verisign and do some fairly extensive
checking before hand, its usually something in address or

order/freight

details.
Regards
Don Grover

[bryan]

Don,

I've sent you a private e-mail, thanks!

Bryan

Don Grover wrote:

Use on Error Resume Next
Log all details
Log the return value if any
Pickup the error number and halt script.
I send my self an email if other than 0 is returned, allong with the
parameter list in a string so I get all data.
The delimiting and data seperators are critical when pasing data to the object,.

If you send me your email, I can send you a script what I use to talk to ver in an automated fashion.
It may help with virifcation
Don
dg*****@assoft. com.au
<br***@chameleo n-systems.com> wrote in message
news:11******** **************@ c13g2000cwb.goo glegroups.com.. .

Don -- Thanks for the reply!

Are you saying that you've seen this error happen just because there was something off in the paramList??? I would hope it wouldn't choke that hard on a bad string.

I would REALLY like to hear if you've seen this happen because of a bad parmList.

I'll take you advice though and start logging. I'm logging the data we used to create the parmList after the crash, but not the actual
parmList itself. I'll start doing that and see if I get something
unexpected.

Unfortunately, I may have to suffer through another crash to see what's going on...

- Bryan

Don Grover wrote:

Write a log file of parmList, Len(parmList), and check it
You will more than likely find an ilegal character or missing value. I move 2-300 at one go through Verisign and do some fairly extensive checking before hand, its usually something in address or

order/freight

details.
Regards
Don Grover