# Create a new credit card object
credit_card = ActiveMerchant::Billing::CreditCard.new(
  :number     => '4111111111111111',
  :month      => '8',
  :year       => '2009',
  :first_name => 'Tobias',
  :last_name  => 'Luetke',
  :verification_value  => '123'
)

if credit_card.valid?

  # Create a gateway object to the TrustCommerce service
  gateway = ActiveMerchant::Billing::TrustCommerceGateway.new(
    :login    => 'TestMerchant',
    :password => 'password'
  )

  # Authorize for $10 dollars (1000 cents)
  response = gateway.authorize(1000, credit_card)

While ActiveMerchant itself is not a risk, I simply want to reiterate how you use the library is very important when it comes to handling credit cards. This code, if used in the manner above, puts your web server in scope for PCI compliance even if you are never writing the credit card number to disk. While you should be doing nearly everything in the PCI standard anyway in order to properly protect your assets, PCI can be a tricky field to navigate. I’ve said it before and I’ll say it again: if you want to avoid the complexity of introducing PCI compliance into your environment, do not store, process, or transmit a credit card number and use an offsite payment gateway instead.

If you have further questions about this, feel free to leave a comment, contact me (damon at startupsecurity.info), or visit PCI Answers for anything and everything related to PCI including contact information for one of the most knowledgeable PCI resources around, Mike Dahn.

PCI Compliance

PCI Compliance has probably been one of the strongest driving factors of security compliance in the US in recent years, particularly for retailers. So what is it? PCI stands for Payment Card Industry and the PCI Data Security Standard is an accepted standard among the payment brands (Visa, MasterCard, Amex, Discover, etc) that defines a set of 12 requirements that merchants who handle cardholder data must be compliant with. *you can breathe now* With that broad statement, there are a few things to point out.

Cardholder Data

Straight from the PCI website…

Cardholder data is defined as the primary account number (“PAN,” or credit card number) and other data obtained as part of a payment transaction, including the following data elements:

• PAN
• Cardholder Name
• Expiration Date
• Service Code
• Sensitive Authentication Data: (1) full magnetic stripe data, (2) CAV2/CVC2/CVV2/CID, and (3) PINs/PIN blocks)

This effectively means that if you store, process, or transmit a credit card number, alone or in combination with the data listed above, you are subject to PCI DSS. I should note, however, that there are different requirements based on your size and processing volume and you should contact your acquirer, payment brand, or local Qualified Security Assessor (QSA) to determine your PCI DSS validation requirements.

The Requirements

So, 12 requirements, huh? Yup. Each with several sub-requirements, too. While you can read the details on the PCI DSS site (click “Download the Specification”), I think it’s more important for startups to realize that there are very specific requirements surrounding the handling of cardholder data and to consider those requirements when extending into such areas as e-commerce. Ultimately the goal is to manage the risk of storing cardholder data by means of network segregation, data encryption, audit logging, policy and security testing (among others). Options are also available for outsourcing credit card transactions, which can relieve the strain of PCI compliance for a startup.

One More Thing

Are you a software developer building a payment application but not actually storing cardholder data yourself? You still need to be aware of PCI and the Payment Application Data Security Standard. This ties in to my previous post about third-party components and is PCI’s attempt to ensure safe handling of credit card data for payment applications created by software vendors.