We are currently tokenizing all MasterCard and Visa cards accepted on our site and not storing card data, but we do not do the same for private-label cards. The private-label cards aren't backed by MasterCard/Visa and can only be used in-store and on our client's website. Are we violating PCI compliance by not treating these cards the same way as Visa/MasterCard even though they are in-effect 'credit' cards.
PCI is more than just Visa and MasterCard. If any of those private label cards are Participating Organization of the Payment Card Industry Security Standards Council you are violating PCI. There are currently 798 participating members.
Private label cards are entirely under the purview of their issuer, if they aren't "cobranded" (by also having a credit card network's logo). The issuer may require PCI compliance, and if they're part of the PCI council (as John Conde's answer says) they are likely to choose to do so. But it isn't required of them.
It's good practice on your part to default to treating them as PCI even if not required, simply because someone may make a mistake and type a regular credit card into the private label card field. However, if the issuer asks you to do something that would be a PCI violation, such as storing the CVV or displaying the full card number to someone, you can safely comply. (If the merchant asks you to do so, without getting approval from the bank that's backing their cards, that could be a problem, but that's between the merchant and the bank.)
Related
I am working on web application where I will have to receive credit card details but only so that I can pass those details to configured payment processor and receive the card id/token which will be stored.
Usually this is done in front-end via JS request directly to the payment processor that will return nonce and then the backend does its job. But this is not my case.
Even though I will not be storing the CC data I will be technically processing them(the CC data enters the server and my code) so I need PCI certification.
But I am not a large company that can afford that so I want to avoid it, at least for now.
So I am wondering if it would be ok from security and PCI DSS point of view to create a Google Cloud function that would receive the CC data, call the application for validation and payment processor configuration, send the CC data to selected payment processor, post the token back into the application to perform what needs to be performed, and return the result from the application back to the client.
Technically, the CC data only enters the Google Cloud function instance which is certified and the CC data is only safely submitted into the payment processor which is also PCI certified. And I think in this case the Self-Assessment Questionnaire D – Service Providers should be enough without the need for certification.
Is my assumption correct?
If you are a service provider, then you need SAQ D for service providers, no matter the setup you're using. Basically if the money that is collected from the credit card goes into someone elses merchant account, then you're a service provider.
SAQ D is the hardest of the SAQs, the difference with 'certification' (there is no certification as such), or RoC, is basically that a trusted body verifies that you've done the SAQ properly. You only need the RoC, which can be in the order of $25K a year, if you process over a certain number of transactions per year.
Yes you should be able to use GCP cloud functions, and that will help with your PCI compliance, but in reality it won't make that much difference regarding the overall effort required to become PCI compliant. You still need to have all the policies and procedures in place, code reviews, SDLC, penetration testing etc etc. It's 139 pages of requirements.
The good news is you don't technically need to be PCI compliant, it's up to the merchant to use PCI compliant providers, and they do that through a contract with you stating their PCI needs. Obviously not the best approach though.
Have a talk with a QSA, it's probably worth a few hundred dollars consulting fees to see if there's anyway around it. If you're doing this as a one off for a single client, it might not be considered service provider for example.
Good luck, and it'd be great to hear what you end up doing.
(Not sure if this is the right place to ask. Please point out other forums if that's not the case).
I'm based in Europe, and I've set up an invoicing system for a client of ours which uses a tokenization system provided by his bank, as part of the bank's secure payment services. (In other words, this is not any of the big american services like Paypal, Braintree, Stripe...).
The problem is that, in order to input a credit card into the system, this
bank needs to charge an initial amount of 0.01 € to it... and when it does that, the credit card owner gets a text message code to approve that charge, without which the card number cannot be introduced. This is not practical for my client, for a variety of reasons. We have asked the bank, and they say that this is all dependant on the card issuing bank, and they can't do anything about it.
My question is...: what do we do to avoid this? From what I remember, other tokenization system I've used also had an initial 0.01 cent charge, and yet I never received any text messages from them (this was a few years ago, admittedly, before 2FA became widespread). How do the big payment processors (Authorize.net, Stripe, etc.) manage to store credit cards without making an initial charge and triggering two-factor authentication in the process?
Thanks.
The reason behind performing an authorisation (not a charge) is to ensure the card is valid before it is stored.
However, the $0.01 authorisation is now considered 'the old way' of doing this. Most card acquirers now allow an authorisation value of $0.00 to be used solely to check the card is valid. This shouldn't trigger any 2FA where it is supported.
Obviously though, this is payment processor dependant on whether they support this 'new' functionality. A small number are still stuck in their ways
The other alternative is just to process the full transaction value. It shouldn't be necessary to submit the card for tokenisation before using it, though admittedly this depends on your business use case.
We use DoExpressCheckoutPayment API function to do payment authorization. The DoExpressCheckoutPayment response has ReceiptID field, which is empty if the payment was funded from a Paypal account or is filled if the payment was by credit card. Is the ReceiptID field also filled if the payment was by debit card? If so, how can we distinguish a receipt is that is for credit card from a receipt that is for debit card? Or is there some other way to distinguish debit card payments? We get a lot of fraudulent transactions with stolen credit cards. Since credit card payments are likely fraudulent and debit card payments are likely good, we would like to have a way to know whether a payment was from credit card or debit card to help us decide whether to accept the transaction or not.
Thanks
No, PayPal does not tell you how one of their accountholders is funding a payment. That information will not be available to you.
If you will permit me to editorialize for a minute, though:
That's a Good Thing, because the reality is much more complex than debit vs. credi. You don't want to try to second-guess all of these possibilities. Payments might be partially funded from multiple sources; have conditional aka backup funding; use "cards" that are neither the debit nor credit networks you are familiar with (e.g. hybrids like China Union Pay, virtual debit cards backed by who-knows-what, ...); various bank draft networks/mechanisms; PayPal lines of credit; etc. In general, PayPal is doing a LOT of sophisticated things to detect fraud and they deliver very low fraud rates for accountholder payments.
Also: if you are processing an accountholder payment (rather than a direct credit card payment), PayPal's seller protection policies replace whatever protections (usually not much!) you would receive from card networks for Card Not Present transactions. These protections do not depend upon what funding the accountholder uses and may be very useful to you. I recommend you read the policies and determine if you can align your business so that most or all of your sales can qualify for these protections.
If your usage cannot be eligible for PayPal Seller Protections, though, then while PayPal still runs their fraud detection they have a pretty limited set of facilities for you to layer on added fraud detection of your own. They will give you a limited amount of information about the accountholder, but as I noted above this does NOT normally include the account's funding source(s).
I am just curious, do PCIDSS regulation requires us to mask the bank account number? i know that credit card numbers need to be masked, but how about bank account number?
Thanks for the answer in advance
No, even with the latest PCI-DDS 3.0 you don't have to mask bank account numbers to be PCI compliant.
All they care about is Cardholder Data, in particular - PAN (Card Number). PAN must be stored encrypted (strong encryption, like AES-128 + KEKs and Keys Management) and masked everywhere it's displayed.
Anything else - including cards expire dates, addresses, bank routing and account numbers - literally, everything besides PANs (excluding CVC code and magnetic strip data [which you can not store under any circumstances]) - you can store in open form, and even display it everywhere and still be PCI compliant.
On the other hand, there's common sense. For security you should encrypt and mask the bank account numbers as well. They can be compromised too, and it won't bring you any good times.
I work for a non-profit organisation and have created and online donations page. Recently this donations page has been used to validate stolen credit card details via the process known as Carding.
The way it works is that a slacker get hold of a whole bunch of credit details but doesn't know which numbers are good or not. So they go to a donations page and attempt a small donation ($5 or less) with the stolen card number. If the donations goes through then they can use the number for bigger purchases.
Carding can cost a non-profit a lot of money as most these "donations" will end being reversed and in some cases a charge back fee will be charged by the bank.
Has anyone else had experience with this? Also, what are some ways that I could stop it?
Off-topic, but I'll bite:
Don't accept "small" donations.
Don't accept "many" donations from the same IP address in a "short" time span.
Consider buying credit card fraud insurance.
What "small," "many," and "short" means is up to you.
If you're not doing this already, consider using PayPal exclusively for accepting credit cards.
With no programming skills required, our Donate button is an easy and affordable way to start accepting donations online.
Discounted rates for 501(c)(3) status
Your donors don't even need a PayPal account
Accept all major credit cards
Source
What they say about fraud protection:
If there's one thing people know about PayPal, it's how seriously we take security. Behind the scenes, we work to help keep you and your donors safe from fraud.
Automatic Fraud Screening
Guard your business with our relentless fraud screens, address (AVS) and card verification (CVV2) checks, and 128-bit encryption—all included at no extra charge.
PCI & CISP Compliance
PayPal adheres to international PCI (Payment Card Industry) and CISP (Cardholder Information Security Program) standards for data protection. These standards are designed to help protect your business from fraud and loss of data. Because we handle the payment card information, you don't have to worry about meeting compliance standards yourself or storing your customers' sensitive financial information.
Full disclaimer: I have no affiliation with PayPal or any credit card company. I do not run, or have any first-hand experience with, an e-commerce site, nonprofit site, or any other web site which accepts electronic payments. I am not a lawyer. I'm just a programmer.