For example, if credit card has the following attributes:
First Name
Last Name
Credit Card Number
CVV
Expiration
Is tokenizing just the Credit Card Number enough to be PCI compliant?
Correspondingly, if tokenizing ACH details and the details include:
ACH Routing
ACH Bank Name
ACH Account Number
Is tokenizing just the Account Number enough to be PCI compliant?
Or, is every attribute required to have its own token such that the number of tokens necessary to be PCI compliant equal to the number of attributes.
ACH is not part of PCI compliance (PCI stands for payment card industry) and it has its own set of rules you must follow (see NACHA compliance).
The point of tokenizing is to hide all of the credit card information from everyone except those who need access to it. The token is then used to represent the card in your system.
What you probably mean in encryption. Firstly, you shouldn't be storing credit card information and, if you require doing so, you should be using a third party to do so. Many payment gateways and services offer this ability and removes most of the PCI compliance burden, and risk, from you. But if you choose to store this data locally, PCI outlines what encryption you may use and what must be encrypted:
Primary Account Number
Cardholder Name (if stored with the account number)
Expiration Date (if stored with the account number)
You also may not store CVV numbers under any circumstances.
Related
According to the api we can authorize the credit card. But in that process we have to put the amount and other information. What if i only want to validate a credit card not to charge it.
Actually i only want to verify whether the user is putting the correct credit card or not. because the system have to go through the hands of laymen.
You can't validate a credit card is legitimate without processing a transaction. You can validate the format of the card number is valid and the card is not expired, but not if it is real or active.
To validate a credit card is valid without charging it you need to do an AUTH_ONLY for either $0.00 or $0.01 depending on your processor's requirements. If it is approved, and the amount is $0.01, you should then void that transaction.
We need to store last 4 digits of credit card, (in order to let customers know which card they have used?) and expiry date (to notify customers that their card is about to expire) for our subscription/recurring payment based SaaS application.
are those two data storage allowed in PCI DSS? Please answer with reference/link to official website or document.
Please note: We are not storing Name On Card and CVV numbers
You should be ok w regard to PCI regulations.
This table lays out what data can be stored:
https://www.pcisecuritystandards.org/pdfs/pci_fs_data_storage.pdf
"If required for business purposes, the cardholder’s name, PAN, expiration date, and service code may be stored as long as they are protected in accordance with PCI DSS requirements."
-edit-
According to the bottom table in that doc, it says you should be able to store those elements. Since you are not storing full PAN, Regulation 3.4 shouldn't apply to the other elements.
If it helps, we got Level 1 certified and we store last 4 and expiration date in clear text. You don't need audited unless you are Level 1 (assuming Merchant here, not Service Provider).
From what I am reading within the PCI Data Storage Do's and Don'ts PDF (https://www.pcisecuritystandards.org/pdfs/pci_fs_data_storage.pdf)
You are able to store the expiration date, service code, and cardholder name so long as you do NOT store the PAN.
Direct quote from the PDF:
These data elements must be protected if stored in conjunction with the PAN. This protection should be per PCI DSS requirements for general protection of the cardholder data environment. Additionally, other legislation (e.g., related to consumer personal data protection, privacy, identity theft, or data security) may require speci c protection of this data, or proper disclosure of a company’s practices if consumer- related personal data is being collected during the course of business. PCI DSS, however, does not apply if PANs are not stored, processed, or transmitted.
Do we need to encrypt all customer information like first name, last name,address or only those data which are related with card payment.
Encrypting any Personally Identifiable Information (PII) is actually a pretty good practice if you can do it.
Pages 7 & 8 of the PCI DSS security standard tell you what needs to be encrypted. The fields in the category of cardholder data all need to be encrypted if stored/transmitted with the PAN. This includes card holder name (among other data), but does not include the card holder address.
I want to validate phone number associated with credit card number during transaction processing using authorize.net. i.e I want to check entered phone number is same as that of credit card issuing bank's record during transaction processing with authorize.net.
If entered phone number is valid & is same with phone number that is associated with credit card then only I can proceed for real transaction processing other wise I will not pass transaction to authorize.net payment gateway.
Can I use auth_only transaction type i.e (x_type= "Auth_only") with $0.0 amount for authorizing request to validate entered phone number with phone number associated with credit card ?
Does card get charged any way or it is get reflected in card statement when we authorize only $0.0 transaction. ?
I do not want to charge card any way or transaction to be displayed in customers statement after authorizing only transaction (x_type= "Auth_only")
Please kindly help how to do this
There is no way to validate a phone number is associated with a credit card because there is no such thing as a phone number being associated with a credit card. A credit card will have a Card number, expiration date, CVV, and billing address. It does not have a phone number associated with it. Additionally, phone numbers are not sent to the card issuing bank so even if there was one, it can't be validated anyway.
i am about to start work on a group-buying site. it works like this: a phone costs 100USD, but if 50 people buy it together , u get a price of 70USD.
so the website launches this offer, waits for 50 people to deposit money . once the threshold is reached, everyone is sent a coupon and that person can go and get his phone.
the problem.. there will be few offers which will be time-limited. for example, total of 100 mobile phones available only. the first 100 users can only buy it. the offer starts on 5th janissary at 11am.
now, how we can detect any suspicious attempts. like a person writing a script and buying all the 100 units.
i dont think IP based limits is a good enough criteria as REAL BUYERS may access the website using the same IP.
environment is LAMP.
why should you care , the more you sell the more you make money :) if the transaction is made you can enforce that user can't buy with same payment method and credentials twice. And as you said user must deposit money before he can make the purchase. You can ask user credit card data before the sale is opened, that is rather good limit as scammer must use 50 different credit cards