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
