Back

TechnologyNov 17, 2010

Break It Down: Online Payment Processing

Brad Buhl

Even in 2010, many traditional retailers are hesitant to go from an in-store card swipe to a card not present (CNP) environment, especially over an online channel. Payment Card Industry (PCI) standards, perceived security threats and a general lack of knowledge in processing payments over the web cause the hesitation. But, have no fear! We’re gonna break it down here.

Term Definitions, aka, ‘Say What?!’

Here’s what a conversation between a retailer and their current payment provider might look like:

Retailer: “Our business is finally ready to go online. We’re setting up the online shopping cart now, and need to make sure we can take all four credit card types at go live.”

Provider: “Excellent news! Since we’re already serving as your acquiring bank and payment processor, we’ll leverage the current issuing bank integrations we have with the card associations.”

Retailer: “Umm…okay…”

Provider: “Is your implementation team accounting for the company being PCI compliant organizationally, or did you want to leverage our payment gateway to keep compliance on our end?”

Retailer: “I’m not sure what the exact plan is, but keeping compliance on your end sounds right.”

Provider: “Great. We’ll just need a development interface that either sends the shopping cart contents to us for payment, or you need to make sure the site is setup on HTTPS, with the right SSL encryption and web services integration to our backend. We’ll utilize a token on your end to call the customer card for payment in the future and resolve any items that could be a PCI DSS concern.”

Retailer: “Say what?!”

If you understood everything the Retailer mentioned above, kudos to you and probably no need to read any further! For everyone else, here’s the first break down, or glossary:

  • Card Not Present (CNP) – the common industry term used for an environment where a physical card is not exchanged between a seller and buyer, such as the internet

  • Payment Card Industry (PCI) – the more general term which includes the use of debit, credit, pre-paid, ATM and point of sale cards and associated business; most people use the term ‘PCI’ and ‘PCI DSS’ interchangeably to refer to the standards, not the general term

  • Payment Card Industry Data Security Standards (PCI DSS) – policies and procedures set by the Payment Card Industry Security Standards Council ensuring compliance with standards of financial data security (including such things as encrypting credit card numbers in the database of record)

  • Secure Socket Layer (SSL) – a protocol for encrypting data which provides security for communications over networks (such as the internet)

  • HyperText Transfer Protocol over SSL (HTTPS) – a protocol used by web servers to transfer and display web content securely (using a combination of HTTP and SSL coding)

  • Payment Processor – a company appointed by a merchant to handle credit card transactions for merchant banks

  • Issuing Bank – the bank or financial institution that offers card association branded payment cards directly to consumers (e.g., Chase offering Mastercard, Bank of America offering Visa, etc.)

  • Acquiring Bank – the bank or financial institution that accepts credit and/or debit card payments for products or services on behalf of a merchant

  • Merchant Account – the acquiring bank contract with the merchant, though the merchant account refers to the line of credit extended to the merchant, and is not an actual bank account

  • Card Association – a network of issuing banks and acquiring banks that process payment cards of a specific brand (e.g., Visa, Discover, etc.)

  • Payment Gateway – eCommerce service that authorizes payments (e.g., the online equivalent of a physical point of sale terminal) and protects credit card details by encrypting sensitive information (such as credit card numbers) between the customer, merchant and payment processor

Hopefully you can now hang with the payment provider discussion. Now let’s break down the process.

The Online Payment Processing Process

When an order is placed on a website, where the customer’s web browser encrypts the data between the customer’s web browser and the merchant’s eCommerce server (via HTTPS), the following process takes place:

Step 1: The merchant forwards the website order transaction details to their payment gateway, over another SSL encrypted connection, with the benefit of the payment gateway keeping sensitive cardholder data, and therefore, in most cases, eschewing PCI DSS responsibility from the merchant to the payment gateway

Step 2: The payment gateway forwards the transaction information to the payment processor used by the merchant’s acquiring bank, put into place via a merchant account; in setting up the payment gateway, the primary information needed is ‘Merch ID’ at the acquiring bank

Step 3: The payment processor (via the merchant account) forwards the transaction information to the card association for approved or declined status

Step 4: After the card association determines the approved or declined status (depending on the type of card used and issuing bank), the payment processor (again, via the merchant account) receives a response code with either an approval code or a denial code with reason (e.g., insufficient funds, network not available, etc.)

Step 5: The payment processor, via the merchant account, forwards the response to the payment gateway

Step 6: The payment gateway forwards the response to relay back to the cardholder and merchant as appropriate for website checkout confirmation

After the process, the merchant submits all approved authorizations, in batch (not in real time), to their acquiring bank in order to settle funds, a process which typically takes three days unless other arrangements are in place.

Who needs a gateway, anyway?

After reviewing the process flow, many question the value of the payment gateway beyond PCI compliance, which could be handled by an extension of the merchant account contract and process. And while most payment processors have their own payment gateways, there is good reason for the bifurcation of processes.

Security is the key reason for employing a payment gateway. Outside of PCI DSS compliance, all those involved in taking payments, from the issuers to gateways to acquirers, utilize a host of security tools in validating a payment is – well – valid. Included in modern security methods are Virtual Payer Authentication (VPA), requesting server Internet Protocol (IP) verification, and even internet geo-location against physical card swipes to proactively monitor theft. Many times, however, the need for a gateway comes down to financial considerations.

From a cash management perspective (for those interested in the business side), payment gateways can also work to provide same day funds availability outside of already established payment processing agreements. Instead of waiting on the funds to clear the acquiring bank, some payment gateways will fund accounts based on the ‘approved’ credit status, and take non-cleared transactions back out of the client account.

Many payment gateways also have relationships with banks for those consolidated bill payment screens we all love to use. While paying all your bills in one place and counting on your bank to send the checks on time is a consumer benefit, businesses are flooded with non-standard checks sent from banks which require manual handling (read: costs more and takes longer to process the payments). Those payment processors with bank relationships can turn these otherwise non-standard physical checks sent via snail mail into an electronic transaction. Lower overall processing costs as well as having cash in hand two to three days before the funding settles feed the need for the gateway, anyway..

Now that we’ve broken it down, it’s time to build it back up – and why not let Credera help you get there?! Some of the questions we could help you break down internally include:

  • Are we comfortable being PCI compliant organizationally?Do we have a preferred rate with regards to transaction charges on our current merchant account?

  • Are there other payment gateway business features such as same day funds availability or channel partnership opportunities which we should consider?

  • How should we strategically separate online vs. in store orders, both from an operational and financial control perspective?

Ultimately, online payment processing should fit into an organization’s vision and strategy, identified either as a core, critical or commodity process. But, that’s for another entry…

Have a Question?

Please complete the Captcha