PCI Compliance: does accepting CC nums on one's site mean type 4 or type 5?

[sneakyimp]

As some of us may know, "PCI Compliance" refers to a data security standard when one accepts credit card numbers for payment. On page 28 of this PDF document describing the PCI standards, it describes the use of a Self-Assessment Questionnaire (SAQ) as well as 5 distinct SAQ Validation Types which basically correspond to different levels of risk/responsibility when one accepts card holder data to perform a transaction.

I believe, but am not sure, that if my website has a securely hosted form (i.e., via HTTPS) that accepts a user's credit card information to perform a transaction but does not store the cardholder information in any file or database or long-term storage then my SAQ Validation Type would be 4. Does everyone concur? Or am I actually SAQ Validation Type 5 because the cardholder information is stored in memory briefly between the arrival of the form submission on my server and the performance of the gateway transaction by my server (e.g., with Authorize.net or Paypal or Amazon Payments or something) ?

Note that the document says :
SAQ Validation Type 4 - Merchants with payment application systems connected to the Internet, no cardholder data storage.

All comments welcome.

[Weedpacket]

I don't think they're referring to storage in volatile core memory during the course of a given transaction.
If they were, then the customer would be storing it in their computer as well (e.g., in the video card's memory while the number is being displayed).

[sneakyimp]

Weedpacket;11047923 wrote:

I don't think they're referring to storage in volatile core memory during the course of a given transaction.
If they were, then the customer would be storing it in their computer as well (e.g., in the video card's memory while the number is being displayed).

I rather thought that was the case, but comparisons to security practices on a user's computer are hardly helpful. I've known people to email social security numbers, credit card numbers, root passwords, etc. Or store a sticky note on their mac that has all the credit card numbers for the office right on their screen.

[Bonesnap]

Are you sure you're not type 1, or any of them? Whenever we have done an ecommerce site we always make sure the client knows we are not storing any payment information (especially credit card) whatsoever. Sometimes they ask us if we can store the credit card and we tell them a resounding NO.

But I am wondering if you are technically a "merchant"? Wouldn't Authorize.Net (or Paypal, etc.) be the merchant?

We do 95% of our work with Authorize.Net and in most cases if we need to use their CIM (customer information manager/module) we only store the CIM ID that it generates and reference from there. Everything about the customer including their payment profiles are stored with them, which I would assume are PCI compliant. I was always under the impression that as long as the "burden" of storing this sensitive information was "passed off" to another service or party, you were being PCI compliant because you're simply not storing any sensitive information. I know that Authorize.Net won't enable your account unless you already have your security certificate for your domain/hosting.

Now I am second-guessing all the ecommerce sites we have done :eek:

[Weedpacket]

Bonesnap wrote:

But I am wondering if you are technically a "merchant"? Wouldn't Authorize.Net (or Paypal, etc.) be the merchant?

No, the merchant is whoever is selling stuff to the customer and receiving money in return. Authorize.Net, Paypal et al. are brokers.

I still don't think holding the credit card information for the milliseconds it takes to perform a transaction counts as "storage". (Can you imagine the fun copyright lawyers could have if having a music app read an MP3 file to play it counted as "copying"?)

[sneakyimp]

Bonesnap;11047963 wrote:

Are you sure you're not type 1, or any of them? Whenever we have done an ecommerce site we always make sure the client knows we are not storing any payment information (especially credit card) whatsoever. Sometimes they ask us if we can store the credit card and we tell them a resounding NO.

I wanted to say I know for sure that I'm not 1,2, or 3, but had to admit to myself that the language in this document is not super-clear. There's a certain lack of precision in the document that I find troubling. Given that this document was created by a supposedly august body of Important Entities, I would imagine they could accomplish a higher degree of specificity. I'm pretty sure my sites are all SAQ Validation Type 4.

Bonesnap;11047963 wrote:

But I am wondering if you are technically a "merchant"? Wouldn't Authorize.Net (or Paypal, etc.) be the merchant?

Technically, I'm not -- I'm a software developer. But the people I work for are merchants. They sell stuff. As weedpacket says, Paypal and Authorize.net are brokers. I might be wrong, but I think that technically they are in the business of escrow.

Bonesnap;11047963 wrote:

We do 95% of our work with Authorize.Net and in most cases if we need to use their CIM (customer information manager/module) we only store the CIM ID that it generates and reference from there. Everything about the customer including their payment profiles are stored with them, which I would assume are PCI compliant. I was always under the impression that as long as the "burden" of storing this sensitive information was "passed off" to another service or party, you were being PCI compliant because you're simply not storing any sensitive information. I know that Authorize.Net won't enable your account unless you already have your security certificate for your domain/hosting.

There is more to being PCI-compliant than passing off the storage of cardholder data to another entity. Passing off the storage of the data to another party relieves you of 90% of the security burden, but you still have to make sure everything is secure that you do actually deal with. If people enter credit card info into a form hosted on your server, you have a substantial amount of responsbility: making sure it's securely hosted, making sure your server is protected against hacks, making sure connections to the payment gateway are encrypted and that you properly verify the cert of the remote host and peer, etc.

Bonesnap;11047963 wrote:

Now I am second-guessing all the ecommerce sites we have done :eek:

You might want to check out Self-Assessment Questionnaire #4.

Weedpacket wrote:

I still don't think holding the credit card information for the milliseconds it takes to perform a transaction counts as "storage". (Can you imagine the fun copyright lawyers could have if having a music app read an MP3 file to play it counted as "copying"?)

Yes I think you are right. "Storage" surely refers to writing data to a file or database. Really frustrating how vague these concepts are.

What do we think about storing a credit card expiration date? If I create a CIM payment profile (or paypal billing agreement) where the "cardholder data" is stored by authorize.net or paypal, surely there's no harm in remembering when this payment method is going to expire?

[dalecosp]

sneakyimp;11047993 wrote:

What do we think about storing a credit card expiration date? If I create a CIM payment profile (or paypal billing agreement) where the "cardholder data" is stored by authorize.net or paypal, surely there's no harm in remembering when this payment method is going to expire?

Perhaps a bit tricky as some transactions can be processed with only two pieces of data, one of them being said expiry date.

CIM only holds some token that allows Authorize.net to ID the card, correct?

[sneakyimp]

dalecosp;11047997 wrote:

Perhaps a bit tricky as some transactions can be processed with only two pieces of data, one of them being said expiry date.

That sounds quite insecure. Tricky? Suppose said expiry date is stored as the expiry date in some table called, say "cim_profiles" ? This table would store the information returned from authorize.net to identify a CIM payment method. Such information would be a numeric ID to identify the record on authorize.net's system, a masked credit card number (e.g., last 4 digits). For example, this is the detail returned from authorize.net when you ask for information about a CIM profile:

Array
(
[payment_profile_id] => 12345678
[type] => creditCard
[masked_account_number] => XXXX8888
[expiration_date] => XXXX
)

I find it interesting that the cc expiration data is masked when you request this info. What's the point in including it at all when it's xxxx every single time?

dalecosp;11047997 wrote:

CIM only holds some token that allows Authorize.net to ID the card, correct?

Yes, using CIM, you can create a 'customer profile' for each of your users -- I think the Authorize.Net system will only permit one customer profile record for each unique user id you supply. Then, associated with each customer profile you can create multiple customer payment profiles. You can then use the id of that customer payment profile (12345678 in the example data above) in order to perform a transaction through the Authorize.Net gateway.

Paypal has a similar concept either called a Billing Agreement or a Reference Transaction. The basic idea is that you use the payment gateway to set up a system where you can bill them by referencing some unique ID.

[sneakyimp]

Bonesnap;11047963 wrote:

We do 95% of our work with Authorize.Net and in most cases if we need to use their CIM (customer information manager/module) we only store the CIM ID that it generates and reference from there.

Bonesnap, I currently have the Hosted CIM iframe solution working, but have been asked to create a form into which users enter their info directly and have our server create the CIM payment profile behind the scenes. Are you doing it this way? If so, could I trouble you for some example code perhaps? I'm sure I can figure it out on my own eventually but it would be nice to see some working code. The Authorize.Net examples are not the greatest.

[dalecosp]

sneakyimp;11048005 wrote:

That sounds quite insecure.

I suppose. It was the de facto standard prior to the 'Net, and may still be in use for "card present" transactions in low-tech locations and businesses. I'm not at all sure any card processor/bank still allows hand scanning with a carbon slider, but I've had that done within the last decade at some place I can't remember off the top of my head ...

I find it interesting that the cc expiration data is masked when you request this info. What's the point in including it at all when it's xxxx every single time?

Same reason gym rats wear muscle shirts? 😉

Yes, using CIM, you can create a 'customer profile' for each of your users -- I think the Authorize.Net system will only permit one customer profile record for each unique user id you supply. Then, associated with each customer profile you can create multiple customer payment profiles. You can then use the id of that customer payment profile (12345678 in the example data above) in order to perform a transaction through the Authorize.Net gateway.

Paypal has a similar concept either called a Billing Agreement or a Reference Transaction. The basic idea is that you use the payment gateway to set up a system where you can bill them by referencing some unique ID.

Makes sense. Thanks, Sneaky! 🙂

[sneakyimp]

dalecosp;11048013 wrote:

I suppose. It was the de facto standard prior to the 'Net, and may still be in use for "card present" transactions in low-tech locations and businesses. I'm not at all sure any card processor/bank still allows hand scanning with a carbon slider, but I've had that done within the last decade at some place I can't remember off the top of my head ...

I have a theory that part of the reason for the decline in violent crime in the US is due to all the crooks going online. I myself was a victim of identity theft earlier this year. From a crook's perspective, it makes perfect sense: no risk of physical harm when perpetrating online, right? In any case, what was the de facto standard before just doesn't cut it these days.

dalecosp;11048013 wrote:

Same reason gym rats wear muscle shirts? 😉

A waste of bandwidth I say. By the way, have you heard the term 'health goth' ?

dalecosp;11048013 wrote:

Makes sense. Thanks, Sneaky! 🙂

Glad to help if I can. Payment gateways are complicated and documentation is often surprisingly poor and SDKs are surprisingly bad. I find the Authorize.Net PHP SDK atrocious and unfriendly.

I also think that PCI Compliance doc is junk. It's so vague. I'm skeptical that any software devs were involved in its creation.

[Bonesnap]

sneakyimp;11047993 wrote:

There is more to being PCI-compliant than passing off the storage of cardholder data to another entity. Passing off the storage of the data to another party relieves you of 90% of the security burden, but you still have to make sure everything is secure that you do actually deal with. If people enter credit card info into a form hosted on your server, you have a substantial amount of responsbility: making sure it's securely hosted, making sure your server is protected against hacks, making sure connections to the payment gateway are encrypted and that you properly verify the cert of the remote host and peer, etc.

All our websites are hosted by a third-party host. Most of our ecommerce sites are hosted with Korax, which we have had a pretty good track record. We do our best to make sure our forms are coded properly and protect against the usual stuff like XSS, CSRF, file upload considerations, SQL injections, etc. Authorize.Net requires access to your form before it gives you your "seal" of approval as a Verified Authorize.Net Merchant (and also require you have your SSL certificate), so I would think that burden would fall onto them.

sneakyimp;11047993 wrote:

You might want to check out Self-Assessment Questionnaire #4.

Meh, I'll let my boss worry about it. :evilgrin:

sneakyimp;11048007 wrote:

Bonesnap, I currently have the Hosted CIM iframe solution working, but have been asked to create a form into which users enter their info directly and have our server create the CIM payment profile behind the scenes. Are you doing it this way? If so, could I trouble you for some example code perhaps? I'm sure I can figure it out on my own eventually but it would be nice to see some working code. The Authorize.Net examples are not the greatest.

Yes, all our interaction with Authorize.Net is through custom-coded forms that we write. I have read about the hosted solutions and iframes and whatnot, but haven't actually used any of those solutions. I should be able to dig up some code where I used the CIM and transactions.

I agree that navigating through their documentation isn't that great. I actually used their test files in the tests folder of the API as a base for what was required when using the CIM, AIM, transactions, etc.

[sneakyimp]

OK so I found a bit of example code here:

    // Create new customer profile
    $request = new AuthorizeNetCIM;
    $customerProfile = new AuthorizeNetCustomer;
    $customerProfile->description = "Description of customer";
    $customerProfile->merchantCustomerId = time().rand(1,10);
    $customerProfile->email = "[e-mail]";
	$response = $request->createCustomerProfile($customerProfile);
	if($response->isOk()){
	$customerProfileId = $response->getCustomerProfileId();
	} else {echo $response->getErrorMessage();}


// Add payment profile.
$paymentProfile = new AuthorizeNetPaymentProfile;
$paymentProfile->customerType = "individual";
$paymentProfile->payment->creditCard->cardNumber = "4111111111111111";
$paymentProfile->payment->creditCard->expirationDate = "2015-10";
$customerProfile->paymentProfiles[] = $paymentProfile;
$response = $request->createCustomerPaymentProfile($customerProfileId, $paymentProfile);
if($response->isOk()){
$paymentProfileId = $response->getPaymentProfileId();
echo $paymentProfileId;

I find it interesting that you can supply a description when creating a payment profile -- I've never seen a description returned when using the SDK to fetch the payment profiles for a user:

// returns really awkward SimpleXMLObjects which contain redundant data and identically named (but different) members, e.g., creditCard
$authorizenet_cim_request->getCustomerProfile($some_authorizenet_customer_profile_id);

EDIT: my mistake! I see that the description is connected to the customer profile, not the payment profile.

[sneakyimp]

I also note that the example above only provides 3 data points (customerType, cardNumber, expirationDate) by assigning nested properties of various objects. It doesn't bother supplying most of the properties described on page 24 of the CIM XML guide.

[Bonesnap]

This code is rather old now but it was the last project I did using the CIM. One thing I remember is that the CIM doesn't validate credit cards, so if you want to make sure the credit card info submitted is valid, you will have to utilize AIM first:

//Begin the authorization of the credit card
$auth 			= new AuthorizeNetAIM(API_LOGIN_ID, TRANSACTION_KEY);
$auth->setSandbox(false); //This is true by default so it's required to be explicitly set when going live
$auth->amount 	= $price;
$auth->card_num = $ccn;
$auth->exp_date = $month.$year; //I believe this has to be MMYY format
$auth->card_code= $cvv;
$auth->address	= $bill_address1.' '.$bill_address2;
$auth->zip		= $bill_zip;

$auth_response = $auth->authorizeOnly();

//If the credit card is approved
if($auth_response->approved)
{
    //If it's approved than continue on...
}
else
{
    //Do something meaningful
    //If you want some example code to handle certain error responses let me know
}

If that's all good then...

//Create the customer profile
$cim = new AuthorizeNetCIM(API_LOGIN_ID, TRANSACTION_KEY);
$cim->setSandbox(false); //Same thing as above - true by default so needs to be set when going live
$customer_profile = new AuthorizeNetCustomer();
$customer_profile->email = $email;
$customer_profile->merchantCustomerId = time();

//Create the payment profile
$payment_profile = new AuthorizeNetPaymentProfile();
$payment_profile->customerType = 'individual';
$payment_profile->payment->creditCard->cardNumber = $ccn;
$payment_profile->payment->creditCard->expirationDate = $year.'-'.$month;
$payment_profile->payment->creditCard->cardCode = $cvv;

$payment_profile->billTo->firstName 	= $bill_fname;
$payment_profile->billTo->lastName 	= $bill_lname;
$payment_profile->billTo->address 		= $bill_address1.' '.$bill_address2;
$payment_profile->billTo->city 		= $bill_city;
$payment_profile->billTo->state		= $bill_state;
$payment_profile->billTo->zip			= $bill_zip;
$payment_profile->billTo->country		= $bill_country;
$payment_profile->billTo->phoneNumber	= $bill_phone;
$payment_profile->billTo->company		= $bill_company;

//Add the payment profile to the customer profile
$customer_profile->paymentProfiles[] 	= $payment_profile;

//Create the shipping address
$shipping_address = new AuthorizeNetAddress();
$shipping_address->firstName 			= $ship_fname;
$shipping_address->lastName 			= $ship_lname;
$shipping_address->address 				= $ship_address1.' '.$ship_address2;
$shipping_address->city 				= $ship_city;
$shipping_address->state 				= $ship_state;
$shipping_address->zip 					= $ship_zip;
$shipping_address->country 				= $ship_country;
$shipping_address->phoneNumber 			= $ship_phone;

//Add the shipping address to the customer profile
$customer_profile->shipToList[] 		= $shipping_address;

//Create the customer profile on Authorize.Net's side
$cim_response = $cim->createCustomerProfile($customer_profile);

//If the creation was successful
if($cim_response->isOk())
{
    //If successful...
}
else
{
    //Do something meaninful
}

If successful...

//Get the profile ID
$customer_id = $cim_response->getCustomerProfileId();

//Get the customer profile
$the_profile = $cim->getCustomerProfile($customer_id);

//Now let's prepare the transaction
$transaction = new AuthorizeNetTransaction();

$transaction->amount = $registration->get_total_price($registration->tax_rate);
$transaction->customerProfileId = $customer_id;
$transaction->customerPaymentProfileId = $the_profile->getPaymentProfileId();
$transaction->customerShippingAddressId = $the_profile->getCustomerAddressId();
$transaction->cardCode = $cvv;
$transaction->tax->amount = $registration->get_tax_amount();
$transaction->shipping->amount = $registration->shipping_rate;

$line_item = new AuthorizeNetLineItem();
$line_item->itemId = '1';
$line_item->name = 'some name';
$line_item->description = 'some description';
$line_item->quantity = (string)count($registration->step_2->pets);
$line_item->unitPrice = (string)$registration->step_3->get_sub_price();//I think i had to cast these to avoid issues
$line_item->taxable = 'true';//lol

$transaction->lineItems[] = $line_item;

//Now charge the card
$response = $cim->createCustomerProfileTransaction('PriorAuthCapture', $transaction);

//Did we get a readable response?
if($response->isOk())
{
    $transaction_response = $response->getTransactionResponse();

//Was the transaction approved?
if($transaction_response->approved)
{
    //Good to go!
}
else
{
    //Do something meaningful  
}
}
else
{
    //Do something meaningful
}

[sneakyimp]

Thanks for that, Bonesnap.

Bonesnap;11048147 wrote:

One thing I remember is that the CIM doesn't validate credit cards, so if you want to make sure the credit card info submitted is valid, you will have to utilize AIM first

:glare:
WTF? Authorize.Net seems to only do the absolute bare minimum. Their SDK completely lacks Javadoc comments which might make it so much more useful and then this. Grrrr.

[Bonesnap]

sneakyimp;11048169 wrote:

Thanks for that, Bonesnap.

No problem! Don't hesitate to ask if you have any other questions.

WTF? Authorize.Net seems to only do the absolute bare minimum. Their SDK completely lacks Javadoc comments which might make it so much more useful and then this. Grrrr.[/QUOTE]
Perhaps surprisingly, Authorize.Net is much easier to work with than either Beanstream or Moneris. We haven't really tried with Paypal; normally we just use their button embed code. Or maybe it's because we are just so used to working with it. shrug

But yeah, the CIM module is strictly for storing customer information, not necessarily validating it.

Heh, I found this in the same project:

/**
 * According to Authorize.Net's documentation, in order to update a customer's payment information
 * you must get their payment profile and create a new payment profile object, and use the
 * corresponding fields to fill in the new object, changing whatever fields need to be
 * changed while the rest remain the same. You then update using this new payment profile
 * object.
 *
 * Seriously.
 */

//Get the customer's payment profile
$payment_profile = $cim->getCustomerPaymentProfile($customer_id, $customer_payment_profile_id);

//Create new payment profile
$new_payment_profile = new AuthorizeNetPaymentProfile();
$new_payment_profile->customerPaymentProfileId = (string)$customer_payment_profile_id;
$new_payment_profile->customerType = 'individual';

$new_payment_profile->billTo->firstName 	= $fname;
$new_payment_profile->billTo->lastName 		= $lname;
$new_payment_profile->billTo->company		= $company;
$new_payment_profile->billTo->address		= $address;
$new_payment_profile->billTo->city			= $city;
$new_payment_profile->billTo->state		= $state;
$new_payment_profile->billTo->zip			= $zip;
$new_payment_profile->billTo->country		= $country;
$new_payment_profile->billTo->phoneNumber	= $phone;
$new_payment_profile->billTo->faxNumber	= '';

$new_payment_profile->payment->creditCard->cardNumber = $_POST['ccn'];
$new_payment_profile->payment->creditCard->expirationDate = '20'.$_POST['cc-year'].'-'.$_POST['cc-month'];
$new_payment_profile->payment->creditCard->cardCode = $_POST['cvv'];

$response = $cim->updateCustomerPaymentProfile($customer_id, $customer_payment_profile_id, $new_payment_profile);

Yeah I don't think you can just simply update a specific line or value; you have to create an entirely new object and fill in all the old fields and only change the ones that need to be changed. Based on the code above, I think I ran into this issue with the updating credit card functionality.