469,271 Members | 1,431 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,271 developers. It's quick & easy.

Problems with Payflow Pro object (PFProCOMControl.PFProCOMControl.1)

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.CreateObject("PFProCOMControl.PFProCOMContr ol.1")

'Transaction through Verisign
parmList = "TRXTYPE=S&TENDER=C&PARTNER=VeriSign&VENDOR=XXXXXX X&USER=XXXXXXX&PWD=XXXXXXX&ACCT=4111111111111111&E XPDATE=0405&AMT=0.01"

Ctx1 = client.CreateContext("test-payflow.verisign.com", 443, 30, "",
0, "", "")

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

client.DestroyContext (Ctx1)

set Ctx1 = nothing
set client = nothing

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

Thanks for your help.
Jul 19 '05 #1
7 5743
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.google.c om...
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.CreateObject("PFProCOMControl.PFProCOMContr ol.1")

'Transaction through Verisign
parmList = "TRXTYPE=S&TENDER=C&PARTNER=VeriSign&VENDOR=XXXXXX X&USER=XXXXXXX&PWD=XXXXXXX
&ACCT=4111111111111111&EXPDATE=0405&AMT=0.01"
Ctx1 = client.CreateContext("test-payflow.verisign.com", 443, 30, "",
0, "", "")

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

client.DestroyContext (Ctx1)

set Ctx1 = nothing
set client = nothing

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

Thanks for your help.

Jul 19 '05 #2
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.CreateObject("PFProCOMControl.PFProCOMContr ol.1")

'Transaction through Verisign
parmList = "TRXTYPE=S&TENDER=C&PARTNER=VeriSign&VENDOR=XXXXXX X&USER=XXXXXXX&PWD=XXXXXXX&ACCT=4111111111111111&E XPDATE=0405&AMT=0.01"
Ctx1 = client.CreateContext("test-payflow.verisign.com", 443, 30, "",
0, "", "")

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

client.DestroyContext (Ctx1)

set Ctx1 = nothing
set client = nothing

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

Thanks for your help.


Jul 22 '05 #3
<br***@chameleon-systems.com> wrote in message
news:11**********************@c13g2000cwb.googlegr oups.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.CreateObject("PFProCOMControl.PFProCOMContr ol.1")

'Transaction through Verisign
parmList =

"TRXTYPE=S&TENDER=C&PARTNER=VeriSign&VENDOR=XXXXXX X&USER=XXXXXXX&PWD=XXXXXXX&ACCT=4111111111111111&E XPDATE=0405&AMT=0.01"

Ctx1 = client.CreateContext("test-payflow.verisign.com", 443, 30, "",
0, "", "")

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

client.DestroyContext (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


Jul 22 '05 #4
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.CreateObject("PFProCOMControl.PFProCOMContr ol.1")
'Transaction through Verisign
parmList =

"TRXTYPE=S&TENDER=C&PARTNER=VeriSign&VENDOR=XXXXXX X&USER=XXXXXXX&PWD=XXXXXXX&ACCT=4111111111111111&E XPDATE=0405&AMT=0.01"

Ctx1 = client.CreateContext("test-payflow.verisign.com", 443, 30, "", 0, "", "")

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

client.DestroyContext (Ctx1)

set Ctx1 = nothing
set client = nothing

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

Thanks for your help.


Jul 22 '05 #5
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


Jul 22 '05 #6
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***@chameleon-systems.com> wrote in message
news:11**********************@c13g2000cwb.googlegr oups.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

Jul 22 '05 #7
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***@chameleon-systems.com> wrote in message
news:11**********************@c13g2000cwb.googlegr oups.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


Jul 22 '05 #8

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

2 posts views Thread by John Siefer | last post: by
reply views Thread by JStrummer | last post: by
1 post views Thread by Mark McEahern | last post: by
15 posts views Thread by Rob Ratcliff | last post: by
26 posts views Thread by jamesbeswick | last post: by
1 post views Thread by Loading name... | last post: by
reply views Thread by Dave | last post: by
1 post views Thread by CARIGAR | last post: by
reply views Thread by zhoujie | last post: by
reply views Thread by suresh191 | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.