Credit Card Transactions -- Payflow/Verisign Performance Woes
Locked
Credit Card Transactions -- Payflow/Verisign Performance Woes
 
|
We're using payflow / verisign for cc processing.
We have 2 batch processes that run each evening. One creates ~5000 orders; and issues a credit card "authorize" transaction. The other completes ~5000 orders; and issues a credit card "capture" transaction. We've found that for both runs the credit card transaction takes 2-3 seconds for each transaction. Not enough hours in the day to get these batch jobs completed before the day starts up again. It seems to me that this is simply unacceptable and I wondered if anyone else is experiencing this problem? Is anyone else out there processing 1000's of batch (offline) cc transactions and getting better response times? Which providers are you using? The response from Verisign was that this is normal . they advised that we upgrade to version 4 of the SDK. Nick |
Re: Credit Card Transactions -- Payflow/Verisign Performance Woes
|
|
2-3 seconds does sound pretty normal. Because there is communication over the internet involved, I'd be surprised no matter how good the code is to see it under 1 second. I'm going out on a limb here... but it sounds like you're processing the orders 1 at a time. Chances are all of the time is spent waiting for network communication as there is natural latency there. Still, you network probably has very good throughput, so this opens an opportunity to run orders in parallel. I'd change your processing service to do more than one order at a time. The pattern is simple, just have 1 "loop" service, and one service that processes one order at a time. In the loop service have it use the dispatcher method that returns a result waiter, and call the single order service 10 times (or 100 times, or some configurable amount so you can tune it) and then wait for the results of each call. Once they are all done, move on to the next set. This is really easy to do with the service engine since it handled the async stuff. BTW, if you're going to do a lot make sure the service engine thread pool size is large enough so they all really do run at once. -David On Dec 3, 2008, at 10:19 AM, Nick Rosser wrote: > We're using payflow / verisign for cc processing. > > > > We have 2 batch processes that run each evening. One creates ~5000 > orders; > and issues a credit card "authorize" transaction. The other > completes ~5000 > orders; and issues a credit card "capture" transaction. > > > > We've found that for both runs the credit card transaction takes 2-3 > seconds > for each transaction. Not enough hours in the day to get these batch > jobs > completed before the day starts up again. > > > > It seems to me that this is simply unacceptable and I wondered if > anyone > else is experiencing this problem? > > > > Is anyone else out there processing 1000's of batch (offline) cc > transactions and getting better response times? Which providers are > you > using? > > > > The response from Verisign was that this is normal . they advised > that we > upgrade to version 4 of the SDK. > > > > > > Nick > |
Re: Credit Card Transactions -- Payflow/Verisign Performance Woes
|
|
From the PayFlowPro Developer's Guide:
"The entire process is a real-time synchronous transaction. Once connected, the transaction is immediately processed and the answer returned in about three seconds." An alternative to David's suggestion might be to modify the services in PayflowPro.java so they will accept a list of orders to process. That might trim some time from each transaction - because the PFProAPI instance can be re-used, instead of being created and torn down on each order. -Adrian David E Jones wrote: > > 2-3 seconds does sound pretty normal. Because there is communication > over the internet involved, I'd be surprised no matter how good the code > is to see it under 1 second. > > I'm going out on a limb here... but it sounds like you're processing the > orders 1 at a time. Chances are all of the time is spent waiting for > network communication as there is natural latency there. Still, you > network probably has very good throughput, so this opens an opportunity > to run orders in parallel. > > I'd change your processing service to do more than one order at a time. > > The pattern is simple, just have 1 "loop" service, and one service that > processes one order at a time. In the loop service have it use the > dispatcher method that returns a result waiter, and call the single > order service 10 times (or 100 times, or some configurable amount so you > can tune it) and then wait for the results of each call. Once they are > all done, move on to the next set. This is really easy to do with the > service engine since it handled the async stuff. BTW, if you're going to > do a lot make sure the service engine thread pool size is large enough > so they all really do run at once. > > -David > > > On Dec 3, 2008, at 10:19 AM, Nick Rosser wrote: > >> We're using payflow / verisign for cc processing. >> >> >> >> We have 2 batch processes that run each evening. One creates ~5000 >> orders; >> and issues a credit card "authorize" transaction. The other completes >> ~5000 >> orders; and issues a credit card "capture" transaction. >> >> >> >> We've found that for both runs the credit card transaction takes 2-3 >> seconds >> for each transaction. Not enough hours in the day to get these batch jobs >> completed before the day starts up again. >> >> >> >> It seems to me that this is simply unacceptable and I wondered if anyone >> else is experiencing this problem? >> >> >> >> Is anyone else out there processing 1000's of batch (offline) cc >> transactions and getting better response times? Which providers are you >> using? >> >> >> >> The response from Verisign was that this is normal . they advised that we >> upgrade to version 4 of the SDK. >> >> >> >> >> >> Nick >> > > |
RE: Credit Card Transactions -- Payflow/Verisign Performance Woes
|
|
David, Adrian,
Thanks for the feedback -- we have considered multi-threaded order processing, async calls etc but my thought was that we should really investigate the 2-3 delay before moving to the next level of tuning. Sounds like 2-3 seconds is not totally unreasonable so we'll start looking at the alternates. I know that our customer is considering alternate providers who can guarantee 0.5 - 1 second processing time so that's an option as well. Nick -----Original Message----- From: Adrian Crum [mailto:[hidden email]] Sent: Wednesday, December 03, 2008 5:50 PM To: [hidden email] Subject: Re: Credit Card Transactions -- Payflow/Verisign Performance Woes From the PayFlowPro Developer's Guide: "The entire process is a real-time synchronous transaction. Once connected, the transaction is immediately processed and the answer returned in about three seconds." An alternative to David's suggestion might be to modify the services in PayflowPro.java so they will accept a list of orders to process. That might trim some time from each transaction - because the PFProAPI instance can be re-used, instead of being created and torn down on each order. -Adrian David E Jones wrote: > > 2-3 seconds does sound pretty normal. Because there is communication > over the internet involved, I'd be surprised no matter how good the code > is to see it under 1 second. > > I'm going out on a limb here... but it sounds like you're processing the > orders 1 at a time. Chances are all of the time is spent waiting for > network communication as there is natural latency there. Still, you > network probably has very good throughput, so this opens an opportunity > to run orders in parallel. > > I'd change your processing service to do more than one order at a time. > > The pattern is simple, just have 1 "loop" service, and one service that > processes one order at a time. In the loop service have it use the > dispatcher method that returns a result waiter, and call the single > order service 10 times (or 100 times, or some configurable amount so you > can tune it) and then wait for the results of each call. Once they are > all done, move on to the next set. This is really easy to do with the > service engine since it handled the async stuff. BTW, if you're going to > do a lot make sure the service engine thread pool size is large enough > so they all really do run at once. > > -David > > > On Dec 3, 2008, at 10:19 AM, Nick Rosser wrote: > >> We're using payflow / verisign for cc processing. >> >> >> >> We have 2 batch processes that run each evening. One creates ~5000 >> orders; >> and issues a credit card "authorize" transaction. The other completes >> ~5000 >> orders; and issues a credit card "capture" transaction. >> >> >> >> We've found that for both runs the credit card transaction takes 2-3 >> seconds >> for each transaction. Not enough hours in the day to get these batch jobs >> completed before the day starts up again. >> >> >> >> It seems to me that this is simply unacceptable and I wondered if anyone >> else is experiencing this problem? >> >> >> >> Is anyone else out there processing 1000's of batch (offline) cc >> transactions and getting better response times? Which providers are you >> using? >> >> >> >> The response from Verisign was that this is normal . they advised that we >> upgrade to version 4 of the SDK. >> >> >> >> >> >> Nick >> > > |
Re: Credit Card Transactions -- Payflow/Verisign Performance Woes
|
|
I also noticed in the PayFlowPro Developer's Guide that the code
supports multi-threading. Probably the best solution is a combination of both ideas - modify the services in PayflowPro.java so they will accept a list of orders to process, and then have each order processed in its own thread. That will allow simultaneous approvals and reduce the overall time. -Adrian Nick Rosser wrote: > David, Adrian, > > Thanks for the feedback -- we have considered multi-threaded order > processing, async calls etc but my thought was that we should really > investigate the 2-3 delay before moving to the next level of tuning. > > Sounds like 2-3 seconds is not totally unreasonable so we'll start looking > at the alternates. I know that our customer is considering alternate > providers who can guarantee 0.5 - 1 second processing time so that's an > option as well. > > Nick > > -----Original Message----- > From: Adrian Crum [mailto:[hidden email]] > Sent: Wednesday, December 03, 2008 5:50 PM > To: [hidden email] > Subject: Re: Credit Card Transactions -- Payflow/Verisign Performance Woes > > From the PayFlowPro Developer's Guide: > > "The entire process is a real-time synchronous transaction. Once > connected, the transaction is immediately processed and the answer > returned in about three seconds." > > An alternative to David's suggestion might be to modify the services in > PayflowPro.java so they will accept a list of orders to process. That > might trim some time from each transaction - because the PFProAPI > instance can be re-used, instead of being created and torn down on each > order. > > -Adrian > > David E Jones wrote: >> 2-3 seconds does sound pretty normal. Because there is communication >> over the internet involved, I'd be surprised no matter how good the code >> is to see it under 1 second. >> >> I'm going out on a limb here... but it sounds like you're processing the >> orders 1 at a time. Chances are all of the time is spent waiting for >> network communication as there is natural latency there. Still, you >> network probably has very good throughput, so this opens an opportunity >> to run orders in parallel. >> >> I'd change your processing service to do more than one order at a time. >> >> The pattern is simple, just have 1 "loop" service, and one service that >> processes one order at a time. In the loop service have it use the >> dispatcher method that returns a result waiter, and call the single >> order service 10 times (or 100 times, or some configurable amount so you >> can tune it) and then wait for the results of each call. Once they are >> all done, move on to the next set. This is really easy to do with the >> service engine since it handled the async stuff. BTW, if you're going to >> do a lot make sure the service engine thread pool size is large enough >> so they all really do run at once. >> >> -David >> >> >> On Dec 3, 2008, at 10:19 AM, Nick Rosser wrote: >> >>> We're using payflow / verisign for cc processing. >>> >>> >>> >>> We have 2 batch processes that run each evening. One creates ~5000 >>> orders; >>> and issues a credit card "authorize" transaction. The other completes >>> ~5000 >>> orders; and issues a credit card "capture" transaction. >>> >>> >>> >>> We've found that for both runs the credit card transaction takes 2-3 >>> seconds >>> for each transaction. Not enough hours in the day to get these batch jobs >>> completed before the day starts up again. >>> >>> >>> >>> It seems to me that this is simply unacceptable and I wondered if anyone >>> else is experiencing this problem? >>> >>> >>> >>> Is anyone else out there processing 1000's of batch (offline) cc >>> transactions and getting better response times? Which providers are you >>> using? >>> >>> >>> >>> The response from Verisign was that this is normal . they advised that we >>> upgrade to version 4 of the SDK. >>> >>> >>> >>> >>> >>> Nick >>> >> > > > > |
«
Return to OFBiz - User
|
1 view|%1 views
| Free forum by Nabble | Edit this page |