Payment Gateways II: Batch Transaction Processing

The purpose of this post is to familiarize merchants and resellers with the concept of batch transaction processing as an advanced feature to be considered during online payment gateway/credit card processor selection.

If this is the first time you are reading “Payment Gateways II” series, please start with the Introduction, as it will improve your understanding of the current post.

Real-time and batch transaction processing

The two ways in which a credit card transaction can be processed provide the basis for two processing approaches. Processing either happens in real time (transactions are authorized one-at-a-time), or it happens in batch (batch file with many transactions is sent and then processed as a whole). While real-time processing is more common in retail, batch processing is more suitable for recurring billing and bill payment (utility bills etc).

The advantage of batch processing is that it allows merchants to track multiple transactions together. This feature is especially important in recurring billing, where a large number of transactions is involved, as batch transaction processing makes it easier to manage the overall process.

Companies that need to process numerous transactions on recurring basis have two options. One option is processing transactions one-at-a-time (effectively emulating batch transaction processing). The other option is actually generating a file and sending it to the payment gateway to process.

If transactions are processed one-at-a-time, authorization and settlement represent two different steps of the process, and if something goes wrong at settlement stage, it is problematic to manage the entire batch. On high volumes of transactions the process can take very long.

The second approach is “cleaner”, primarily because transaction authorization and settlement happen at the same time: the whole procedure is done “in one shot”, there is no need to do reconciliation of the settlement at the end. File-based batch transaction processing is also suitable for merchants that process e-checks (ACH transactions), because it makes the delivery of ACH transactions somewhat easier (one file, containing all transactions, is generated).

Let us consider a health club example to illustrate how batch transaction processing works.

Example

A health club runs recurring billing daily to collect membership dues. In addition to that it also runs a decline recycling process (reprocesses all the declines on the subsequent day). As part of the decline recycling process another attempt is made on all of the declines. Real-time processing is possible, it makes it very difficult to keep track of the transactions, processed for a given billing date, and can, potentially, be time-consuming on those billing days when large numbers of accounts need to be processed. File-based batch transaction processing, on the contrary, provides an opportunity to view every billing date within the context of a batch and transactions that go through recycling process simply constitute a portion of that main batch (sub-batch), which makes things considerably more manageable for a large-size fitness club chain.

Conclusion

Based on merchant’s current or future/potential needs, the merchant that needs to process considerable number of recurring billing and bill payment transactions should consider looking for a processor capable of processing large files.

The next article will cover credit card decline recycling.

Payment Gateways II: Credit Card Convenience Fees

The purpose of this article is to familiarize merchants and resellers with the concept of transaction surcharges as an advanced feature to be considered during payment gateway/processor selection.

If this is the first time you are reading our “Payment Gateways II” series, please, start with the Introduction to improve your understanding of this post.

Some businesses require surcharging a fee on top of the original transaction amount. The two most common surcharge examples are credit card convenience fees and taxes.

Credit card convenience fees

Every time a merchant processes a transaction, there is a processing cost associated with it. Traditionally it used to be covered by the merchant. However, there is a practice of applying a credit card convenience fee, functioning as a surcharge on the original transaction, to pass the cost of processing to the cardholder. Historically associations, such as Visa, MasterCard tried to discourage the practice, but under the pressures of businesses they’ve accepted it. As a consequence, many merchants are now able to afford credit card processing, because they are charging convenience fee to cardholders.

Credit card convenience fee implementation

Credit card convenience fee can be processed as part of the original transaction or it can be processed as a separate transaction, resulting in two transactions on the card. The first option is often considered a better one; it is preferred by Visa, and, from cardholder’s viewpoint, it involves just a single transaction. The second option is unpopular with card associations, especially with Visa.

If a merchant business is limited in the capability of doing two transactions, it needs to go with a processor capable of accommodating the surcharge in a single transaction. If a business chooses to use two transactions through two different MIDs then it will need to somehow handle the situation when the second transaction doesn’t go through because of insufficient funds or network communication error.

A mechanism very similar to the one used for credit card convenience fees is also used for surcharging of taxes.

While support for surcharges is not a very critical factor, and the entire decision, whether to go with a processor or not, is not going to be based on it, it should be considered. So merchants should discuss the support for surcharges of credit card convenience fees with their processors.

Let us look at a real-life example of how credit card convenience fees are used.

Example

A bill payment service company has an online payment portal that utility companies can use to collect past due balances from their customers. The bill payment company wants to surcharge a 5 % convenience fee on every transaction processed to cover the costs of processing and its services.
The simplest way for the company is to send a single transaction and then get its 5 % as a rebate back from the processor. The ability to charge a credit card convenience fee as part of the original transaction and receive the money back from the processor as a form of rebate at the end of the month (or simply get its 5 % automatically deposited to its account the day after the transaction is processed) reduces the complexity of integration process for the bill payment company. In either case payment processing logic within the bill payment application becomes considerably easier (as there is no need for logic targeted at processing of credit card convenience fee as a separate transaction).

Conclusion

Businesses that need to charge credit card convenience fees should go with a processor that has native support for that. When evaluating processors’ convenience fee support capabilities, businesses should pay attention to the available mechanism (one transaction vs two transactions); the decision regarding processor selection should be made based on the specific business requirements.

Payment Gateways II: Introduction

In a previously published series of posts we have covered a set of basic features to be considered by merchants and resellers as online payment gateway selection criteria. Posts concerning these fundamental features can be found in Payment Gateways series on our web-site.

Although needs of most merchants and resellers are confined to the features discussed so far, enterprise merchants, wholesale resellers, independent sales organizations (ISO) and payment service providers (PSP) occasionally face some challenges induced by their size and specifics of their business. For the benefit of these groups of players, we have decided to write another series of articles covering the so-called advanced enterprise-level payment gateway features. In the current series we will offer a review of advanced features (which are sometimes no less important than basic ones) to be considered when choosing a credit card processor or online payment gateway provider.

In the installments concerning basic online payment gateway features we have considered merchant and reseller perspectives separately for illustrative purposes. In contrast to basic features, where the two specified perspectives could be clearly defined and understood, enterprise features tend to apply to both resellers and enterprise merchants in the similar way. The only thing for resellers to keep in mind is that a reseller must always strive to select a processor\online payment gateway, capable of supporting the set of features, satisfying all current and potential needs of merchants this reseller is dealing with.

Consequently, in our subsequent posts we are going to look at all of the above-mentioned players from a single perspective. In either case, we will try to supplement the concept explanation with a meaningful example from the industry.

Particularly, this series will look into the following advanced online payment gateway features:

  • Ability to support surcharges (such as convenience fees and taxes);
  • Support for batch transaction processing (especially if there is a need to do recurring billing\process large files);
  • Support of ACH transactions through unified ACH\CC API;
  • Blacklist capability of “never-to-be-active” accounts;
  • Availability of various types of recurring billing schedules;
  • Support for tokenization and hosted paypages (to reduce PCI scope);
  • Built-in merchant on-boarding and merchant account provisioning mechanism (to automate the merchant data collection process);
  • Enterprise reporting for advanced reconciliation;
  • Payment aggregation and remittance for PSPs;
  • Credit card BIN and “business intelligence” (to allow businesses to gain extra-knowledge about their customers).

All aforementioned topics (and more) will be covered in subsequent articles, so stay tuned and wait for new installments to appear.

Payment Gateways: Chargeback Information

The purpose of this article is to cover chargeback handling as an advanced feature to be considered by merchants and resellers when selecting a payment gateway\credit card processor.

If this is the first time you are reading our “Selecting a Payment Gateway” mini-series, please, start with the Introduction to improve your understanding of this post.

To learn about chargeback concept and why chargebacks are important, check the respective article on our web-site. Chargebacks represent problems for both merchants and resellers because of financial liability with them. A crucial point to be kept in mind is that if chargeback rate of some business exceeds 1 %, this business gets on the Terminated Merchant File and its merchant account is shut down.

Merchant perspective

While chargebacks are unavoidable, the goal of any business is to handle chargebacks properly whenever they appear. That means: find out about potential chargeback as soon as possible (retrieval), contact the customer, respond to retrieval and try to resolve the issue, prevent the chargeback from getting enforced and having financial impact.

When dealing with a processor\payment gateway it is important to understand:

  • how chargebacks are going to be delivered to the merchant (chargeback delivery mechanism),
  • what information is going to be present in a chargeback (chargeback identification method),
  • how the chargeback disputing mechanism will work.

These three aspects are addressed below.

Chargeback delivery mechanisms

In terms of chargeback information delivery from a processor to a merchant the two common options are: over e-mail (fax) and as a report (through API).
In case of e-mail or fax delivery, for every chargeback that occurs, a merchant is going to receive an e-mail or fax with the chargeback details. The report/API option offers delivery of chargebacks in electronic format (for example, as a delimited file), which can then be either used for manual processing or imported into merchant’s system of record.
For larger businesses with high transaction volumes an importable report/API would definitely be a more preferred option.

Chargeback identification methods

There are two approaches the processors might use to identify a chargeback. Based on the approach they use, merchants will receive slightly different information about a chargeback.
One of the ways is to use the unique identifier of the original transaction which is included in the chargeback case. However, some of the legacy platforms are incapable of doing this, and instead they send the merchant the date, the amount and the last four digits of the card number. While this option is acceptable on some smaller transaction volume, it will be a labor-intensive task for those who process a lot and want to handle chargebacks. Consequently, whenever possible, the preference should be given to processors capable of including unique ID of the original transaction in the chargeback information.

Chargeback disputing mechanisms

In terms of disputing (merchant-processor interaction) there are two ways of handling chargebacks (providing supporting documentation against the chargeback claim). One is through e-mail or fax, and the other – by using automated customer relationship management system (CRM) API.
While still predominant in the industry, the first option might be inefficient, as it involves a lot of manual work. The second option is going to help a business automate the process, but it may require resources to put it in place.
Consequently, if a merchant needs to handle a small number of chargebacks, it can go with the manual process. However if a merchant wants the chargeback handling to be an efficient automated mechanism, the preference might lie with processors who use some formal API for chargebacks disputing.

To illustrate the common issue with chargebacks, let us consider the example of a health club.

Example

A health club customer may buy something and then forget about the purchase. When the statement arrives, the customer might want to dispute the charge. Consequently, the health club must handle the issue appropriately: learn about the chargeback as soon as the customer disputes it, find the specific transaction resulting in the chargeback, contact the customer, explain the situation, and resolve the issue. Delaying response to the initial retrieval might result in the actual chargeback, lost revenue for the club and increase of the club’s chargeback rate.

Conclusion

Depending on transaction volumes, merchants must select processors/payment gateways capable of providing the most suitable options in terms of chargeback delivery, identification and disputing. A merchant dealing with larger transaction volume would prefer to partner with a payment gateway/processor whose chargeback handling mechanism is fully automated and implemented in a formal API.

Reseller perspective

The issue with chargebacks affects all resellers in one way or another (as chargebacks tend to be viewed negatively by acquirers), but it is particularly vital for payment service providers (PSP), participating in the underwriting process and bearing financial responsibility for the merchants in their portfolio. In such cases if a merchant is incapable of covering the chargebacks, PSP might be responsible for refunding the money back to customers. Therefore, it is of paramount importance for any PSP to be aware of all of the chargebacks as soon as they occur, as this awareness gives them the opportunity to react and, potentially, resolve the issue with the merchant before it is too late (the merchant is out of business).

Example

A health club (merchant) working with a fitness software company (which also provides merchant services, i.e., acts as PSP) is going out of business. People who signed term agreements for twelve months are now demanding their money back. Under normal circumstances the merchant is going to refund all the money, but there are cases when the money is no longer there and the merchant disappears. If the reseller is able to see the increase in chargebacks quickly, there is still time to react and, potentially, withhold some of the funds from the merchant.
If a PSP usually has a multitude of merchants in its portfolio, it is virtually impossible for this PSP to resolve chargeback issues with all of them “manually”.

Conclusion

If a reseller business is bearing financial responsibility for chargebacks issued by customers of its sub-merchants, it is better for this reseller to use API in order to control the process across entire portfolio and get the information as quickly as it arrives.

In the subsequent posts we are going to move on to more advanced features, targeted at enterprise merchants, wholesale resellers, ISOs and PSPs.

Payment Concepts: Cardholder Data Flow

This is the final installment in a mini-series of posts dedicated to PCI compliance. The purpose of this particular article is to familiarize merchants that have to accept payment card data and store it, so that their software is involved in cardholder data flow, with some solutions, allowing them to improve their flexibility in terms of PCI compliance.

If you have not read the intro, we recommend that you start with it, as it will improve your understanding of the current post.

The general solution, allowing merchants’ front-end software (web-site\CRM) not to be involved in cardholder data flow is to avoid touching credit card information. There are three ways to accomplish this: using a filter, using a hosted payment page (PayPage) or using a server request interceptor.

Cardholder data filter

When a merchant has a big and complex application with many different data flows, and it is desirable to take the application out of scope, it is possible to reconfigure the system in such a way that all of the incoming and outgoing messages are going through a sanitizing filter (so that the main application is connected to the outside environment only through this filter). The filter could use some sort of algorithm cleaning the credit card information from the incoming messages (replacing it with tokens) and inserting credit card information into the outgoing messages.

This scenario is intended for more complicated systems that need to receive messages from clients and exchange messages containing credit card data with other systems.

This filter solution is a server-oriented one, capable of reducing the PCI scope of a business (because the filter application is still touching the credit card data) but not of completely eliminating its PCI responsibility.

Hosted payment page

Hosted payment page is a common solution for smaller applications that simply need to process payments (and require credit card information only for that).

If the needs of the merchant are confined to accepting payments in a secure way and keeping its own front-end application out of scope, it can rely on a hosted payment page to collect credit card data.

In essence, a PayPage is a web-page that contains fields to gather credit card information. The merchant supplies the payment amount (how much to charge) and description (what to charge for) to the PayPage, and the PayPage collects credit card information and then processes the transaction (pushing the result back to the merchant via callback).

For example, a merchant has a shopping cart as part its own web-site. At the time that payment needs to be collected, a redirect to the PayPage occurs (specifying the payment amount and the information on what the payment is charged for). The PayPage (residing on a PCI-compliant server of the merchant’s payment processor) takes care of the rest. The user enters credit card information and the merchant gets a payment confirmation, or transaction response, which might include token for the merchant to store if it needs to reuse the card in the future.

Server request interceptor

An interceptor is somewhat similar to the filter, only it operates on the client’s side and is used as a solution for web-applications. The interceptor is a script (usually, Java script) residing on a PCI-compliant server, that attaches itself to a static form (responsible for taking in credit card information), and is able to intercept the request when the customer puts in all of the information and hits the “Submit” button. The form gets rendered, the user enters credit card information and submits the form. The script then intercepts this request and sanitizes it by dynamically extracting the credit card information, converting it into tokens and re-inserting them in the request, that is subsequently sent to the server.

Since the page itself is static, the interceptor script itself comes from a PCI-compliant server and the request hitting the server no longer has the credit card information in it, the entire application is, technically, out of PCI scope.

Conclusion to the PCI compliance mini-series

Although the final decision is always made by the assessor\auditor (especially, when a merchant is processing large volumes of transactions), there is a whole range of solutions allowing merchants to reduce their PCI scope or get out of it. So, even if a merchant doesn’t have resources to go through the full PCI audit, there are still ways allowing the merchant’s business to accept credit cards.

Our development has experience of using all three types of techniques, so if you need an advice on implementation of any of the described solutions, do not hesitate to contact us via our “ask question” page.

Payment Concepts: Credit Card Tokenization

This article belongs to the mini-series providing guidelines for merchants interested in attaining PCI compliance. In this installment we are going to cover the approaches to credit card tokenization and possible solutions that make PCI audit more attainable.

If you have not read the intro, we recommend that you start with it, as it will improve your understanding of the current post.

Credit card tokenization concept

The idea behind tokenization is to delegate credit card storage to the payment gateway or payment processing system, as opposed to business-specific software, such as web-site, online storage or CRM. The main purpose of tokenization is to allow merchants not to store credit card numbers for repeated\recurring transactions. To achieve this, credit card numbers are replaced by tokens which are saved and used instead.

Fundamentally, there are two primary approaches to tokenization.

Approaches to credit card tokenization as a process

The two conceptual ways to implement credit card tokenization are commonly referred to as pure tokenization and profiling.

Pure tokenization

Under pure tokenization approach, only credit card (bank account) number is tokenized. However, if necessary, routing number (identifying the branch of the bank) for ACH, social security number, or even driver license number, could be tokenized as well. To put it simply, every sensitive value is replaced by a token (one for one).

When the credit card processing request is issued (during repeat\recurring transactions), the token is used instead of a credit card number, allowing merchants to avoid credit card storage.

Profiling

The second approach to credit card tokenization (profiling) is a bit more elaborate, as it involves maintaining the full or partial customer profile.

The difference is that in this case the entire billing information, including the billing address, shipping address etc (depending on the system used) would be stored in the customer profile (including credit card number). When a transaction is processed, the ID of the profile is sent, and any fields that are not supplied, are “pulled” from that customer profile.

Some systems use a variation of customer profiles where instead of customer profile an ID of the previous transaction is passed and all of the missing information, such as credit card number etc, is extracted from that transaction.

When repeated\recurring credit card transaction is processed, the profile ID (or ID of the previous transaction) is used in place of the actual credit card number, thereby allowing the merchant to avoid persistence of the credit card number.

Advantage of the first approach is that the business doesn’t have to do any separate maintenance of the profile. It only has one number and the token just replaces it. Advantage of the second approach is that more information can be stored outside of the merchant’s system (web-site\CRM). Consequently, if the merchant has some basic front-end system and doesn’t wish to store all the billing information (ZIP code etc), it can rely on tokenization provider to store that information, which might be more convenient for the merchant. However, with this approach the merchant assumes the responsibility for keeping the profile up to date.

Now let us look at the most common ways to implement credit card tokenization.

Credit card tokenization through appliance

Tokenization through appliance is intended for the pure tokenization approach, described above.

The appliance is a combination of a hardware device (used to encrypt\decrypt credit card numbers) and PA-DSS-compliant software (used to store encrypted values and to generate tokens). The hardware device is usually either a chip on the motherboard or a PCI-card. The appliance (hardware with software written on top of it) is hosted in local network of the merchant\PSP.

Hardware\appliance solution does not eliminate the need for PCI-compliance certification, but it definitely reduces the scope and simplifies the PCI audit, as the storage is delegated to an already PA-DSS-compliant piece of software.

Credit card tokenization through appliance can be an ideal solution for a merchants\PSPs processing large volumes of transactions and already having an existing PCI environment where the appliance could be deployed.

Credit card tokenization as service

The other approach is hosted tokenization service, where, instead of having some type of device in merchant’s own network, the merchant is delegating storage to some other (third) party. In this case the merchant must use some form of API to generate the tokens.

When it comes to credit card tokenization as service, there are 3 conceptually different approaches with minor technical distinctions, nevertheless, important and worth noting:

  • Processor-integrated tokenization – tokenization is an integrated service of the payment processor. The advantage is that the merchant only deals with one and the same party for credit card tokenization and processing. In order to process a transaction there is no need to de-tokenize credit cards (or even to “touch” the actual card number, because it is stored by the underlying processor). If a token is already obtained by the merchant, when transaction is processed, the merchant simply passes this token to the processor and the processor is able to locate the respective credit card number. Under this approach switching to another processor would result in costly data extraction and re-location procedures. And data extraction fees are sometimes really heavy.
  • Gateway-integrated tokenization – the approach is similar to processor-integrated tokenization, except that tokenization is handled by and independent gateway (possibly, servicing several processors). The advantage of this approach is that if a merchant switches from one processor to another (serviced by the same gateway) the tokenization procedure remains the same and costly re-tokenization process is not required. Under this approach the merchant does not touch the card data, remaining completely out of PCI scope.
  • Third party tokenization – cards are stored by the by the third party separate from the one who processes transactions. The merchant uses the API to tokenize/detokenize cards on demand. This option is a little less secure, because although the merchant doesn’t store card number, before it processes the transaction, it has to de-tokenize the transaction, take the actual number and send it to the processor. The merchant is touching but not storing the card number. So, this solution reduces the merchant’s PCI scope, but does not take the merchant out of it.

The next and concluding post in this mini-series will cover payment card data flow and respective solutions allowing merchants to reduce or even get out of PCI scope.

Payment Concepts: Payment Card Data Storage

This article is the second one in a mini-series describing recommendations to be considered by merchants interested in attaining PCI compliance. In this installment we are going to look into the reasons behind payment card data storage and possible solutions that make PCI audit more simple.

If you have not read the intro, we recommend that you start with it, as it will improve your understanding of the current post.

Reasons behind payment card data storage

There are several reasons for payment card data storage:

  • for reporting purposes and to look up previous transactions
  • for issuing of refunds
  • for repeat purchases and recurring billing

Let’s take a closer look at each of them.

Payment card data storage for reporting and transaction lookup

The question to consider here in terms of payment card data storage is whether it is really necessary to store credit card numbers for future transaction lookup.

If a business is storing the info for reporting purposes without actually doing anything with the card number, it can just store a part of that number (for some merchants it might be sufficient to store just the last 4 digits, solely for identification purposes).

For lookup purposes by full account number merchants can use one-sided hash (information on hashing algorithms can be found here. A common way is to use SHA-256 hashing function with multiple iterations and salt to ensure that the data is hacker-proof.

The hash value is unique, the number of iterations is difficult to guess, and the salt is difficult to crack. Even if the hashing algorithm was determined, the number of iterations established, and the salt guessed, it would still take a considerable amount of time to decode card numbers using brute force approach.

Generally, storage of the last 4 digits and one-sided hash is considered acceptable, but the final “verdict” will depend on your specific auditor.

Payment card data storage for issuing of refunds and transaction settlement

In some cases, merchants would process credit card transactions and store payment card data in order to be able to issue a refund (return money) on the card if the cardholder returns merchandise. Sometimes, certain processors will require full credit card information to settle transactions at the end of the day.

In both cases (refund and settlement) merchants need to consult with the current payment gateway or payment processor to see if there is an alternative option to return money or to perform settlement.

If a merchant needs to return money to a customer, many present-day processors and gateways support refund operation using reference number. When the original sale transaction is processed, a reference number is returned back to the merchant. Subsequently, it is possible to issue a refund passing only the reference number back to the processor, and effectively returning money for that transaction without supplying the original credit card number.

Those, experiencing the problem around settlement (usually, associated with terminal capture) should consult their current payment gateway and see if there is a host settlement (capture) option available that would eliminate the need for sending credit card information at settlement time.

Payment card data storage for repeat purchases and recurring billing

The most common payment card data storage solution for repeat purchases and recurring billing is tokenization. Instead of getting and storing the credit card number, businesses, wishing to have support for repeat purchases and recurring billing, are getting a token from a PCI-compliant tokenization provider. Thus, they can store a token instead of the card number, and reuse it in subsequent transactions\purchases, while reducing their PCI scope.

The concept of tokenization and respective options available to merchants for effective payment card data storage and PCI scope reduction will be covered in the next post.

Payment Concepts: PCI Compliance

The purpose of this mini-series of articles is to familiarize small and medium-sized merchants with the concept of PCI compliance and with available solutions allowing them to reduce their (or even get out of) PCI scope.

What is PCI compliance about?

With the advance of credit card processing technologies, the scales and types of credit card fraud also witnessed considerable extension. To prevent manipulations with credit card data during credit card processing, Payment Card Industry Compliance (or PCI compliance) requirements were introduced (more detailed info can be found here).

While there are many businesses wishing to accept and process credit cards, relatively few are equipped with all the tools and resources necessary to meet strict PCI certification regulations. As a consequence, there are some solutions available to smaller and medium-size merchants, allowing them to get out of PCI scope or simplify their PCI audit (reduce their PCI scope).

Before moving to detailed coverage of these options, it would be appropriate to list the key PCI compliance requirements that are defined and maintained by PCI Security Standards Council (PCI SSC).

PCI standards

PCI DSS stands for Payment Card Industry Data Security Standard. The standard specifies the requirements to be followed by an organization, dealing with payment cards. These requirements are primarily meant to ensure credit card data protection and prevent security violations. Any business wishing to attain PCI compliance must follow the PCI DSS standard. Requirements and objectives to be followed by businesses, according to PCI DSS, can be found here.

In addition to PCI DSS standard, concerning PCI compliance of businesses operating with payment cards, there is a more concise standard for payment card processing software, called PA DSS (Payment Application Data Security Standard). PA DSS lists the requirements to be met by payment processing applications in terms of cardholder’s data protection. The complete list of PA DSS requirements can be found here.

To keep track of all PA DSS compliant applications a special list of Validated Payment Applications is maintained by PCI SSC.

In a nutshell, PCI DSS is targeted at businesses that accept credit cards (such as retail stores, health clubs, collection companies and others) and those that offer payment applications in hosted mode (such as payment processors, payment gateways and e-wallet companies).

PA DSS, on the other hand, is targeted at software packages, manufactured by companies, which do not necessarily operate with payment card data themselves, but software products of these companies are distributed to end users (who do process credit cards) and installed on their machines (or in their networks). In general, PA DSS requires these products to ensure security of payment card data processing.

More information on standards and other PCI SSC documents can be found here.

The two components of PCI compliance

At the high level, businesses that deal with PCI compliance face two issues:

  • Cardholder data storage – should credit cards be stored, how should they be stored, who is going to bear the liability for storing of the cards.
  • Cardholder data flow – at which point a credit card is accepted, swiped vs keyed card processing, which software is used to process credit cards, how the card gets persisted.

While it is generally understood and accepted that storing cards puts a merchant in PCI scope, people often tend to misunderstand the concept of card flow, thinking they are not in the scope, while actually being in it.

In the subsequent articles, we are going to present some guidelines to follow while evaluating your card storage strategy and general card data flow, and provide suggestions on how to make PCI compliance more attainable and PCI audit – less labor-intensive.