Skip to Content

A new trend is emerging in the world of credit card security which is often referred to as “Beyond PCI”.  This new trend is also moving into the SAP market as more and more SAP customer look for solutions to eliminate the entry of RAW credit card numbers completely from their SAP applications in order to remove those applications from scope of a PCI audit.

What exactly does “Beyond PCI” mean?  Simply put it means doing more than simply meeting the 12 requirements of the PCI DSS standards that all merchants accepting credit cards as a form of payment are required to comply with.  And which of those 12 requirements tends to receive the most visibility in an SAP environment?  Requirement 3 (Protect stored cardholder data) and Requirement 4 (Encrypt transmission of cardholder data across open, public networks).

Recently a trend is emerging among the companies I speak with regarding how to address the PCI DSS requirements in their SAP landscape.  Some companies are running only an SAP ERP system, others may also be running SAP CRM or have a Web Store in which customers can place orders.  In all cases the company is concerned with how to best address Requirements 3 & 4 regarding secure storage and transmission of cardholder data.  And increasingly companies are expressing a desire to prevent entry of RAW credit card numbers and cardholder data into their applications, over their networks and via their hardware. 

But what exactly constitutes “cardholder data”?

To define “cardholder data” let’s look at page 4 of the PCI DSS v1.2 requirements dated October 2008.  The following table identifies what data constitutes “cardholder data”:

image

The footnotes are of particular importance for this discussion – especially footnote #1:

image

Per the table, cardholder data includes:

  • Primary Account Number (PAN) – the credit card number itself 
  • Cardholder Name
  • Service Code – (CVV or CID)
  • Expiration Date

However, footnote #1 states the following, “PCI DSS, however, does not apply if PANs are not stored, processed, or transmitted.”  So if you are not storing, processing or transmitting a PAN in your system then PCI DSS is not applicable – but how is that possible?  Let’s look at a few possible options.

The most obvious option would be to stop accepting credit cards as a form of payment.  However customer demands for credit cards as a form of payment plus make this impractical.  The benefits to the merchant that accepts credit cards, such as lower Days Sales Outsanding, shifting the credit burden/liability to the credit card issuer and a payment guarantee prior to shipment (authorizing the card) make acceptance of credit cards attractive to merchants.

Perhaps you could consider outsourcing your sales and/or collections functions to a third-party and let them take on the PCI DSS burden.  If your company is not directly receiving credit card numbers from customers and then processing those payments in your systems there would be no need for storage, processing or transmission of that sensitive cardholder data.  But of course not every company can, or desires, to outsource that function to someone else.

Another option, which will still allow you to take advantage of the payment card processing business logic in your SAP and other applications, is to prevent entry of RAW card numbers into the system through tokenization.  In a previous Tokenization as a means of securing credit card numbers I discussed the benefits of tokenization, particularly when outsourcing the tokenization functionalty to an external third-party.  If a RAW card number (PAN per the PCI DSS requirements) is never entered into your applications then PCI DSS does not apply even if you are storing a token in place of the PAN and the remaining data elements that constitute cardholder data.

One way to tokenize credit card numbers prior to the RAW PAN entering a Merchant environment can be seen in this diagram depicting a tokenization process in an Web Store scenario.

 

image

The steps are as follows:

  1. The end customer places an order on the Web Store
  2. Customer prepares to checkout and make payment
  3. The Merchant Web Store calls Data Intercept to begin card number capture process.
  4. Data Intercept renders a field on the Merchant Web Store checkout page in which the end customer will enter the credit card number
  5. The end customer enters the RAW card number in the Data Intercept hosted field – outside of the Merchant Web Application thus keeping the Web Application out of PCI scope 
  6. Data Intercept sends the RAW card number to the be Tokenized (the encrypted string is stored in the Paymetric data vault)
  7. Data Intercept receives back a Token
  8. The Merchant Web Application receives the Token
  9. The Merchant Web Application submits an Authorization Request using the Token in place of the RAW card number
  10. The Paymetric service forwards the Authorization request to the Processor
  11. The Processor sends the Authorization Request to the bank which issued the card
  12. The Issuing Bank returns the Authorization Response to the Processor
  13. The Processor returns the Authorization Response to Paymetric service
  14. The Paymetric service sends the Authorization Response (with Token) to the Merchant Web Application
  15. The end customer is shown an Authorization Response and the checkout is complete
A similar approach can be taken when orders are entered directly in the SAP GUI as is outlined in the following diagram.
image
In this case the steps are as follows (this process flow includes the Settlement as well as Authorization logic):
  1. The end customer calls the Merchant call center to place an order
  2. The Customer Service agent opens up a Data Intercept Web Page hosted by Paymetric and enters the RAW card number thus preventing SAP from being exposed to a RAW card number
  3. Data Intercept sends the RAW card number to the be Tokenized (the encrypted string is stored in the Paymetric data vault)
  4. Data Intercept receives back a Token and the Customer Service agent copies the Token and Pastes it in the SAP Order in the Payment Card Number field
  5. During Order Save SAP requests an Authorization and sends the Token to the Paymetric CA-PCI RFC adapter in place of a RAW card number
  6. The Paymetric CA-PCI RFC adapter converts the Authorization Request to aWeb Service call and forwards it to the Paymetric service
  7. The Paymetric service forwards the Authorization request to the Processor
  8. The Processor sends the Authorization Request to the bank which issued the card
  9. The Issuing Bank returns the Authorization Response to the Processor
  10. The Processor returns the Authorization Response to Paymetric service
  11. The Paymetric service sends the Authorization Response (with Token) to the Paymetric CA-PCI RFC adapter
  12. The Paymetric CA-PCI RFC adapter sends the Authorization Response (with Token) to the SAP Order and the Order is saved
  13. The Order is delivered
  14. The Delivery is Billed and the Authorization Response details (with Token) are copied from the Sales Order to the Invoice
  15. The Invoice is posted to Accounting and the Authorization Response details (with Token) are copied from the Invoice to the Accounting Document
  16. The Settlement process is executed (typically as a nightly, scheduled job)
  17. A Settlement Clearing Document is posted to Accounting as a result of the Settlement process
  18. The Authorization Response details (with Token) of each item in the Settlement Batch are read from the corresponding Accounting Document and sent to the Paymetric CA-PCI RFC adapter
  19. The Paymetric CA-PCI RFC adapter converts the call to a Web Service call and sends the Settlement Batch details (with Token) to the Paymetric service
  20. The Paymetric service responds to the Paymetric CA-PCI RFC adapter (with Token) that the Settlement Batch has been received
  21. The Paymetric CA-PCI RFC adapter responds to SAP (with Token) that the Settlement Batch has been received by the Paymetric service
  22. The Paymetric service sends the Settlement Batch details to the Processor
  23. The Processor sends each transaction from the Settlement Batch to the corresponding Issuing Bank
  24. The Issuing Banks respond to the Processor with notification of processing of funds
  25. The Processor initiates the Settlement Batch deposit at the Merchant Depository Bank
  26. The Merchant Depository Bank notifies the Merchant that a deposit has been made and a Manual Settlement Reconciliation is performed in SAP
In both scenarios above the entry of RAW card numbers has been prevented in SAP through the use of Tokenization and Data Intercept technologies.  Because a RAW card has not been entered or displayed in SAP the SAP system can be considered out of scope because, per the quote on page 4 of the the PCI DSS v1.2 requirements, “PCI DSS, however, does not apply if PANs are not stored, processed, or transmitted.”  
To report this post you need to login first.

Be the first to leave a comment

You must be Logged on to comment or reply to a post.

Leave a Reply