A Secure Payment Gateway provides an encrypted connection between a web site’s Secure Server host and a non-internet based Processor, or Card Network, allowing for an Authorization to be requested and received in Real-Time.

Please see Real Versus Non-Real Time Processing

There are two primary models of the Secure Payment Gateway:

I – The Third Party Secure Payment Gateway:

In this model, the Third Party Secure Payment Gateway’s server-computers have to provide a connection between the merchant’s web site and the Visa/MC (or Check) Merchant Processor. This is done via telephone (or leased land line). The Merchant Processor will receive the transaction through it’s non-internet modem bank, and then send the transaction through it’s direct connection to the Card Network (like Visa) for approval. The Merchant Processor returns a response via land line to the Secure Payment Gateway, which encrypts the message and transmits it over the web back to the originating secure web site host. The Third Party Secure Payment Gateway is a different company than the Merchant Processor, and has it’s own fees that are separate from any Merchant Processing fees. Examples of these are Cybercash and Authorize.net.

– Rather than try and create their own Secure Web System, many Banks and Bank/Processor alliances will use a Secure Payment Gateway Provider to perform this task for them.

II – The Proprietary Secure Payment Gateway:

A Merchant Processor with it’s own proprietary Secure Payment Gateway can connect securely to their merchants’ web sites using it’s own systems; transactions are sent from the Web Site’s Secure Server directly to the Merchant Processor’s Secure Servers, which then route the transaction to the Card Network via their on-site direct-connection for authorization. These types of Processors save merchants money by eliminating the need for yet another service provider, the Third Party Secure Payment Gateway.

– Processors that own their own proprietary Secure Payment Gateway are more competitive and usually offer their gateway services at no additional cost.

Encryption Technology:

Secure Internet Transactions are performed using “SSL” Secure Socket Layer encryption technology. When a customer selects to purchase an item and they decide to pay by credit card, their Web Browser is told to open up a Secure Connection to the Web Site Host’s Secure Server; the URL will change so that the “http:” changes to “https:” , which indicates that the server is secure. When a web browser is connected to a Secure Server, a small Padlock will appear at the bottom right corner of the screen to indicate the Secure Connection, meaning that all information being passed is encrypted for transmission. The Secure Web Site Host will upload the customer’s credit card or check information along with all other order information, and assemble a transaction using the merchant’s merchant account number and PIN, and then send the transaction to the Processor or Gateway’s Secure Server.

Secure Payment Software:

– In order to conduct secure business on the web, the Secure Gateway Provider runs a Secure Host System, and sells/licenses/gives away software modules that allow Shopping Carts and other applications to request and receive Credit Card Authorizations via their system using encrypted communications. (This is called Real-Time Authorization.) Some companies provide these as free-license, open-source software modules.

– The other features of this Secure Payment Gateway software are the functions provided to merchants online when they connect to the Secure Payment Gateway host; merchants can access their own account information via Online Reporting, use a “Virtual Terminal” to conduct transactions, handle administrative tasks, etc. (These features all reside on the Secure Payment Gateway Provider’s Host computer system.)

– Online Reporting provides for all credit card sales reports, check sales reports, banking and settlement reports, and returned item reports to be automated and available over the internet 24 hours a day. Online Reporting is one feature that the Third Party Secure Payment Gateway companies sell to merchants; companies that have their own proprietary Secure Payment Gateway typically provide Online Reporting at no extra cost to the merchant.

Secure Payment Gateway Provider Fees:

– The Third Party Secure Gateway Provider typically charges a Software License Fee or “sells” the Software Module through ISO’s, ISPs, Agents, and Banks. (Usually the cost to the Processor or ISO/Agent is $99.00, and this amount is marked up to $499.00 to $699.00 for resale to the merchant.)

– These Third Party Secure Gateway Providers also typically charge a Monthly Access Fee for the Secure Gateway. This fee is usually marked up by the ISO, Agent or Bank that brings in the clients. (Usually the cost to the Processor or ISO/Agent is $10/month, and is marked up to $20 to $39.95 a month to the merchant.)

– Some Secure Payment Gateway Providers also charge an additional Transaction Fee.

– Because the Secure Payment Gateway Provider generates their income by linking a Processor to a Merchant, they must charge fees above and beyond what a store front merchant would pay for the same transaction processing services; Processors that have their own Secure Payment Gateway can often provide a more cost effective internet processing service because they do not have to pay a Third Party Processor for this service, and consequently, they often do not charge the merchant additional fees for the Secure Payment Gateway, Software Module, or Online Host Software.

Virtual Terminals:

Internet Processors and Secure Payment Gateways usually provide a “virtual terminal” that allows merchants to log on to the processing center and hand-key in new transactions. Some also provide a means of issuing credit transactions to the merchant’s clients. The Virtual Terminal is a large selling point for third party Secure Payment Gateways, but is a common element of Internet credit card and check processing that you should not have to pay for. Look for the Processor that has their own gateway and that does not charge extra for Real Time Processing, Online Reporting and Virtual Terminals.

Examples:

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, such as Cybercash and Authorize.net, 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.