Quick Links: Home > CC Solutions > Real-Time Internet Processing > ...

Real-Time Processing
vs.
Non-Real-Time Processing

Real-Time Processing means that when a web site's customer conducts an online purchase, that the check or credit card information is conveyed to the Processor at that exact time so that an authorization can be requested and received at that moment. Real-Time Processing always implies that a Secure Payment Gateway is being utilized, whether proprietary or third party.

Non-Real-Time Processing means that while the credit or check information is passed from the customer to the web site's server in encrypted form, it is not passed to the Merchant Processor at that time. The information is collected and stored throughout the day, and later on, the merchant must submit the transactions for authorization and capture using a point of sale terminal or PC. The merchant must then inform any declined customers via email, phone or mail. In this type of transaction, the merchant is acting as their own "Secure Payment Gateway", by acting as the "link" between the internet and their Merchant Processing company. 

Examples:

Non-Real-Time Credit Card Capture:

• Customer elects to check out their purchases made on a shopping cart or order form on a merchant's web site. 
• Customer selects to pay by credit card.
• Customer's browser brings up the secure payment form by connecting to the website host's secure server.
• Customer enters in his or her credit card information on the secure payment form, and authorized the transaction.
• The transaction information flows to the website host's secure server using SSL encryption.
• The merchant's web site server saves this transaction information in the merchant's shopping cart or administrative application residing on the host, and sends a receipt page to the customer's browser.
• Some time later, a batch of these credit card transactions is assembled by the merchant or web site administrator.
• This batch of transactions is sent to the merchant's credit card processor via a PC (with direct modem connection to the processor), or possibly by entering the transactions into a point of sale terminal (like the ones used in brick and mortar stores.)
• Only at this point will the merchant find out if the cards are able to receive authorizations for the amounts requested.
• The merchant receives the responses on their batch authorization request, with some of the transactions being approved and authorizations issued, and some transactions being declined.
• The merchant manually posts this information to their web site's administrative data base, and the corresponding orders are either initiated, or canceled due to declined cards. 

Real-Time Credit Card Authorization & Capture:

• Customer elects to check out their purchases made on a shopping cart or order form on a merchant's web site. 
• Customer selects to pay by credit card.
• Customers browser brings up the secure payment form by connecting to the website host's secure server.
• Customer enters in his or her credit card information on the secure payment form, and authorized the transaction.
• The transaction information flows to the website host's secure server using SSL encryption.
• The secure server connects to the merchant's processing bank either via a Secure Payment Gateway (a third party which provides the connection to the processing bank via land line) or directly (some processors have their own proprietary secure payment gateway and therefore do not require any third party to provide the secure gateway). 
• The processor polls the card network, such as Visa or Master Card, directly, and the validity of the card and availability of funds is confirmed.
• If approved, an authorization code is returned to the processor, or to the Secure Payment Gateway from the processor. 
• The authorization is encrypted by the Payment Gateway or processor and transmitted in encrypted form to the web server of the merchant, which triggers fulfillment of the order.
• The merchant's web server will then send the customer's browser a confirmation receipt. 
• The amount due is moved from the card holder's bank to the merchant's processing bank.
• The merchant's processing bank moves the money to the merchant's local bank.

Real-Time Check Authorization & Capture:

• Customer elects to check out their purchases made on a shopping cart or order form on a merchant's web site. 
• Customer selects to pay by Check.
• Customers browser brings up the secure check payment form by connecting to the website host's secure server.
• Customer enters in his or her checking account and ID information on the secure check payment form, and authorized the transaction.
• The transaction information flows to the website host's secure server using SSL encryption.
• The secure server connects to the merchant's processing bank either via a Secure Payment Gateway (a third party which provides the connection to the processing bank via land line) or directly (some processors have their own proprietary secure payment gateway and therefore do not require any third party to provide the secure gateway). 
• The processor connects to their Check Processor/Originator, usually an outside company, and sends the check information for authorization. 
• The check and ID information is "verified" against a data base of bad check writers and closed accounts to see if this item is a bad risk, and also if the information is formatted correctly or contains any mistakes.  (With checks, the merchant cannot be sure that they are good until they have "cleared", after submission to the check writers bank.) (Some internet check programs offer a guarantee on these transactions for a percentage fee on all checks processed.)
• If the verification is approved, an authorization code is returned to the processor.
• The processor then sends the authorization to the Secure Payment Gateway. 
• In some cases, the Secure Payment Gateway, Processor, and Check Processor/Originator, are all the same company.
• The authorization is encrypted by the Payment Gateway or processor and transmitted in encrypted form to the web server of the merchant, which triggers fulfillment of the order.
• The merchant's web server will then send the customer's browser a confirmation receipt. 
• The check transaction is converted into an ACH Debit Transaction by the Check Processor/Processor and submitted the their ODFI or Originating Financial Institution. At the same time, a second Credit transaction is sent to the ODFI for payment to the merchant.
• The ODFI submits the transaction into the ACH Network.
• The ACH Network sends the transaction to the Check Writer's bank.
• The check writers bank, or RDFI (Receiving Depository Financial Institution) receives the item and attempts to post it to the check writer's (receiver) account. 
• If the funds are available, then the transaction is complete. When accepting checks, merchants may want to allow five to seven days for the items to clear prior to shipping any goods or fulfilling the order. 
• If the funds are insufficient, or if the ACH Transaction failed for other reasons, the item is returned to the ODFI via the ACH System. The ODFI notifies the Originator, who notifies the processor (if separate). The processor then reverses the transaction and takes the money back from the merchant. 

For further reference check out: Secure Payment Gateway