As I know, for EMV cards, before transaction taking place, the terminal perform Card Authentication (using Static Data Authentication or Dynamic Data Authentication) to make sure the card is not a fake card.
(In reverse, it seem that there is no way for POS Terminal Authentication)
In Google Play, there are many applications can read EMV card data.
With a NFC-enable smartphone, we can read the sensitive card information including card number and expiration date.
(And the same for contact EMV card by using a smartcard reader)
My question is:
For EMV cards, is there any standards which specifies 'mutual authentication' protocol between cards and terminals.
And the card only send card data to terminal after performing 'mutual authentication' step.
Thanks,
Nothing to my knowledge. I believe this is so because the business use case does not justify this requirement.
Case 1. As you said there are readers who can read card data. However if at all someone take all the data from the card and replay it on a terminal, since transactions are protected by a single use cryptogram, and unpredictable number is provided by terminal, it will fail.
Case 2. A fraudster after forging a card can get some goods/services and leave, but for the terminal, it has to be registered to an acquirer/bank. There cannot be zombie terminals. Hence it is terminal who want to check the genuineness of the card and not the other way around.
You can get the track/card from chip, but so does mag stripe.
There is nothing like Mutual Authentication in EMV Payment Transaction between Terminal & Card.
Since every transaction is based on some transaction specific unique data & cryptography then cloning is not possible (here I am not talking about SDA cards).
Even though any reader is able to read the data (which is actually allowed by EMV), Since these readers application is not authorized by EMV, so they can't use the VISA/MasterCard servers for transaction processing.
(Extending existing answers with another point of view)
During online transaction card validates that terminal is able to communicate with card issuer -- i.e. that the terminal is able to deliver card-generated ARQC to the issuer and is given a valid ARPC.
As Gaurav Shukla notes in his answer fake terminals are not able to communicate with respective payment association servers.
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.
I have an application that requests Credit Card information to do a payment to a third party company.
My application captures the CC, CVV, Expiration Date, etc. and then passes that information to their API that charges the customer.
I've been reading about PCI Compliance but based on the following image, I am not quite sure what level of compliance I would need to meet.
Lastly, I would like to figure out what would be the best options for me in case I have a new purchase from the same client. Since I am not charging the customer but the third party does, how would be the best way to store the payment information so user doesn't need to enter his information every single time they want to use my service? What would be the implications of storing payment information on my servers from a PCI compliance point of view? Is there a way where I don't need to store the payment information for the user but I can pass their information (if they are a returning customer) to 3rd party API and still being PCI Compliance?
Since you're building a web application (even embedded into Facebook messenger), if you're building out the form that collects card data, you're going to either fall under "Shopping Cart - Payment Page Direct Post" (which is A-EP) or "Shopping Cart - Payment Page Not Outsourced" (which is D-Merchant). You really want to be under A-EP if you can, but you may not be able to.
The difference between the two is whether or not the card data crosses through your servers. With "Direct Post", the web page itself sends the data (usually via HTTP POST) to the payment API, and you have no way to capture it. With "Not Outsourced", the data comes back to your server, which then calls the payment API and passes it along. In that case, you're going to have to go through the entire D-Merchant questionnaire (by far the longest, other than D-Service Provider), and probably have a special environment set up to prevent anything from trying to read the card data as it transits your server.
There's really no part of the card data that is worth storing to try and identify a repeat purchaser, because you won't have the payment data to actually complete a payment. Instead, you should see if your payment provider provides any type of "token", which can be used to identify that payment data later. If so, you can associate that token with the customer (however you identify a customer) and reuse it when they return.
Further reading: https://www.pcisecuritystandards.org/documents/SAQ_InstrGuidelines_v3-1.pdf
(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 have implemented the Card Security Code check when using credit cards.
This produced a value on the attribute security_code_check of passed, failed, unknown.
Balanced state "It's strongly recommended you do not process transactions with cards that fail this check."
However the security code check is not done until an authenticated operation is performed against it the card.
So by the time the check is done we have attempted to process the card. So how do we follow the advice not to use it?
Creating a hold on the Card to do this is wrong and unnecessary. Doing so ties up a customer's available funds and causes confusion.
An authenticated request claims a tokenized funding instrument to a marketplace, which triggers Card verification at the same time. This is discussed in several places in the documentation, chiefly in https://docs.balancedpayments.com/1.1/guides/balanced-js. If you wish to check the CVV result before attempting to charge the card, you should perform an authenticated request on the Card such as a GET, or even associate the Card to a Customer resource. This will initiate the Card verification and provide the ability for you to check the verification results before attempting to charge the Card. Immediately attempting to debit the Card does not provide such an opportunity.
"However the security code check is not done until an authenticated operation is performed against it the card."
An authenticated operation includes performing a GET on the card token returned by balanced.js, which is required to store the card anyway. It is not required to debit the card first.
You would create a hold on the card first. If the CSC succeeds, capture the hold. If it fails, void the hold.
I plan on using a service such as Authorize.net to process user's credit cards. Which brings two questions.
Will I need SSL on the payment page even though I will be letting the third part handle most of the processing?
Will I need to get the user's address? And if so, will an apartment number be required? (If they have an apartment, of course)
Yes. The processing will most likely be done through some API that you will call. So getting the information from your users from the browser to your server will require encryption (SSL)
That depends on your set up and what Authorize.net will require.
You DO need to use SSL for your portion of the transaction - you are not PCI-DSS compliant if you do not.
If you are asking about apartment number because you intend to pass it to A.net for AVS anti-fraud checking, AVS only checks the part of the address line before the first space eg: 123 Maple St - only the 123 is checked. The zip is the only other part of the address checked, so there is no reason to worry about apt number. Collect it for your own complete records of course, but it will not affect and AVS check which is the only reeason to give it to A.net in the auth transaction.
It depends on which API you use. If you use any of the hosted APIs (SIM, hosted CIM) you will not need an SSL certificate as you will never be handling any sensitive information on your website.
If you use AIM, ARB, CIM, or DPM you will need an SSL certificate as you will be collecting sensitive information which is covered by the PCI DSS standard.
Yes and no. You are not required to collect it as it is not needed to process a credit card. However, without it you cannot perform Address Verification (AVS) which is a good tool for helping to reduce fraud. It also means your transactions will be processed at a higher rate which is not a good thing.