Batch vs. Real-Time Processing in e-commerce environments

I was having a discussion recently about payment processing in e-commerce environments, specifically Batch versus Real-Time Authorizations. Batch processing has a one-a-day connotation, or that it is simply file based.  Why would you not want to send transactions real-time was the question to me? 

My Answer:  Any time you are not face to face with a customer or if there is a delay before the customer receives the product or service, you should do Near-Time authorizations with the intent of not allowing the mechanics of the authorization impact the customer.

Let me explain:

It comes down to the customer checkout experience as well as to help prevent shopping cart abandonment the payment process should not be an impediment to the customer ordering an item. Especially if there is a glitch, communication issue, or any other outage in the authorization process including late or slow replies. You don’t want your customer to get frustrated during the order process, because they will go some where else to shop.

What is an alterative approach ?

Take the order, log it in a Database with a status of "Payment Pending" or "Authorization Pending"  Have a batch process or scheduled task or cron job that runs on a periodic basis to loop through the list of Orders with Pending Payment Statuses, Securely acquire the required authorization data elements required for the authorization request (Considerations need to be made regarding the retention of CVV2 subsequent to the authorization request, and how the authorization data is managed between the order and authorization request ) and perform Near-Time Authorizations for these orders. Approval responses update the Order Records in the Database, and "errors" and are placed to try again at the next run (Consider Reversals and Duplicate Transaction Checking here on error responses to protect your customers open-to-buy) Declines are noted as Payment Failed, and you send a payment email allowing your customer be notified that the authorization failed, and prompt them to update their payment information on a Secure Account Web Page or call you to provide it over the phone. (Note this method wont work if you are doing any 3D-Secure – Verified by Visa, MC Secure Code , stuff — Which I’ve used I think 2 times in the last 5 years.)


Our you could do it real time and put a message on your cart to your customer, "Please Try Again Later" when an issue occurs with your payment gateway or processor — They will Try Again Later, somewhere else.


In retail environments (or in e-commerce environments with large volume) where real-time is required, you need a redundant payment switch that can handle multiple outbound connections to your processors primary and secondary authorization centers (geographical diversity in their data centers) that run on separate connections (routers, outbound copper, and different telcos)  but also read this here, Andy talks about this in a little more detail, and talks about geographical diversity that runs though a common CO in an issue that a client had with an authorization provider.


  1. Wouldn’t a mix of both be a better approach? Use real time auths and if a real time auth fails, then instead of relaying a failure message to the consumer, the merchant could retry the auth at a later time?

  2. “Wouldn’t a mix of both be a better approach?” With this I would be concerned with the time involved before determining the failure – and customer will wait until the request times-out or returns an error code.

  3. Great post, you put it clear enough I was able to follow your thoughts. Based on db and BJR’s comments I’m assuming a mixed approach isn’t standard practice? If its not, why not? I love how you illustrate the bottom line- customer checkout experience. Our jobs are to ensure that their experience is as seamless as possible, loved how you wrapped it all up!