I'm trying to detect whether a contactless enabled smartcard or a mobile device equipped with ApplePay, Google Pay, or Samsung Pay was used for a contactless EMV transaction.
I have been researching via the EMV books, and there seems to be a tag 9F6E provides this sort of data:
EMV Book 3 - VISA
EMV Book 4 - MasterCard
Questions:
VISA provides a 4 byte value in the field 9F6E, but I can't find a list of possible values and their meanings anywhere. The EMV book says "out of scope". Is there anyway to reliably convert this to a known form factor?
MasterCard provides data 2 bytes for the form factor, but I'm seeing values that I don't undestand (32 31 ascii = 21). Is there a list of values and meanings somewhere for these?
Is there an easy way to understand if CDCVM has been used for a given contactless transaction, so that I could separate contactless transactions from contactless with CDCVM transactions?
Google Pay is using cloud-based payments while Apple is using an embedded secure element. You can find this tag on 9F6E form factor on Visa. However, it might be different for Master Card or Amex.
To fix this correctly, you might want to check the EMV tag 9F19 which returns to the token requestor ID. Check EMV payment tokenization for this spec. Token requestor ID looks like this:
MasterCard
50110030273 – APPLE_PAY
50120834693 – ANDROID_PAY
50139059239 – SAMSUNG_PAY
Visa
40010030273 – APPLE_PAY
40010075001 – ANDROID_PAY
40010043095 – SAMSUNG_PAY
40010075196 – MICROSOFT_PAY
40010075338 – VISA_CHECKOUT
40010075449 – FACEBOOK
40010075839 – NETFLIX
40010077056 – FITBIT_PAY
40010069887 – GARMIN_PAY
Refer the below documents. You will require Visa Online and MasterCard connect access to get these.
VCPS_2.2 Spec
M/ChipRequirements For Contact and Contactless Spec
check in CVM and CVR inside 9F10
I believe it is also possible to detect if the transaction was performed by a mobile device by using tag 0x82 (Application Interchange Profile). I believe this is a better approach because it will be the same regardless of card brand (as long as the card brand in question followed EMVCo's spec correctly.
Here is a link to EMV Co Contactless Book.
https://www.emvco.com/wp-content/uploads/2017/05/C-4_Kernel_4_v2.6_20160512101635327.pdf
Screenshot Of Desired Table
Check Bit 7 (second most significant bit) of Byte 2 (Rightmost Byte). If it is 1 it came from a mobile device. The Application Interchange profile will always be 2 Bytes.
I'm am currently working on a POS web app, where we use the credit card swipe functionality. I'm planning to use the card reader:
MagTek 21073062 Dynamag Magnesafe Triple Track Magnetic Stripe Swipe Reader with 6' USB Interface Cable, 5V, Black
I tried out swiping the credit card and get my final card data as follows:
"%B4111111111111111^FIRST/LAST^1010000000000000000000000000000?;4111111111111111=11111111111111119080000000000000000?|0600|F8861EC73F7BD2790D4EE2DBB7935B039DE9653DE90D240C1257E225FBB987837B779D29246D9D516A94FE9F770396FE6AD2A5F3312108DF35BB512F4BA22A84FF3BB6CDFC008024|669078686F127D2A0660BBBE6C7BD3F708ED1B42216F41E37F3DCF59DB02C77452337456C9F5141D||61403000|190894CFA8A9E46A350C2E758DC1D83A798980BF5319298583E13DC98C62272C8C732D07B2713B1FACE8DBF6CE16B57C94360610CD6FFE46|B2E15B9061015AA|789A6E205C421D40|9011080B2E15B9004018|1CA3||1000"
Data interpreted to according to Financial Cards
The card number according the response above, the card number is "4111111111111111"(for representation purpose). The problem is the number in the response is not correct. The first 6 digits and the last 4 digits seems to be fine, but the digits(6 in this case) in the middle seems to be incorrect(does not match with the swiped card). This happens to all the cards I swipe. Tried the same card multiple times(to check if hardware problem) , still the same result.
Any help on this issue will be appreciated.Thanks in advance.
When the card is generating arqc algorithm, does card number play any role ? In other words: having 2 brand new cards with ATC set to 0 and having the same CDOL, will they generate the same arqc ?
Card number and ATC are involved in session key generation. So every card will generate a different cryptogram.
Since I am not sure whether you are referring to the same card number (Assuming you were able to clone a card :) Still the cryptogram generated will be different for your first try for your both cards . If you look for CDOL, you can see an element unpredictable number( which is generated by terminal ). This is a 4 byte numeric field and chance of getting this generated same twice is very rare. Even in case where unpredictable number is same, still you need all other elements in CDOL same (amount, currency, country date atc etc) to get the same cryptogram. To block even this rare possibility issuers maintain the last used ATC for each card that it will not accept any ATC same or less. Hope it is clear.
Based on what data does a POS terminal decide if it needs to generate a ISO 8583 100 (Authorization Request) message or a ISO 8583 200 (Acquirer Financial Request) message.
Also how does POS decide if it needs to prompt the user to enter his card PIN or not.
Any reference to documents on ISO 8583 message generation at the POS will be very useful.
Thanks
A 200 message is what ISO 8583 calls a Financial Message. It is used to transfer funds into or out of a cardholder's account.
A 100 message is what ISO 8583 calls an Authorization Message. It is used to check that the card holder's account has enough funds to cover the amount of the transaction and to reserve that amount (and sometimes a little more) for a certain period of time. It does not actually take any funds from the account. At a later time, a 200 (actually a 220) message can be sent to take the money from the account).
100 message are usually used in situations where the transaction amount is not known at the time or where the delivery of the good or service is not immediate.
So for example, when you check into a hotel, the hotel wants to know that your account has enough funds to cover your expected stay (and maybe a little extra in case you order room service or use some other service), so a 100 message might be sent when you check in, and then at checkout time, a 220 message is sent to actually transfer the funds from your account.
See the "Message Class", "Message Function" and the "Examples" sections of this Wikipedia entry on ISO 8583.
As far as, "how does the Point of Sale (POS) device decide if it needs to prompt the user to enter his card PIN or not", there is no one answer that works in all situations, for all merchants, and in all countries.
For example, in some cases, PIN entry is required for all debit cards but not allowed for any credit cards. In these cases, the POS device needs to know whether the card being used is a debit card or a credit card. It can either ask the operator or it can attempt to use the card number and/or mag stripe to determine this. A table of account numbers or Account BIN numbers (the first few digits or the account number) can be stored in the POS and used to identify the type of card (sometimes). see Bank Card Number).
Sometimes just knowing whether a card is credit or debit is not enough, there are cards that can be used as either, there are debit card that can used without a PIN, and there are credit cards that allow/require PIN entry.
Both credit card terminal and credit card have a list of preferred customer verification methods, the most common ones being 'signature', 'PIN', and 'identification'.
The terminal then takes the verification method that is ranked highest by the card and supported by the terminal.
Possible Duplicates:
Best practices for taking and storing credit card information with PHP
Storing credit card details
Storing Credit Card Information
I need to store credit card numbers within an e-commerce site. I don't intend on storing the whole credit card number, as this would be highly risky. I would like to store at least the first five digits so I can later identify the financial institution that issued the card. Ideally, I would like to store as much of the credit number as I safely can, to aid any future cross-referencing etc.
How many digits, and which particular digits, can I safely store?
For example, I imagine this would not be safe enough:
5555 5555 555* 4444
Because you could calculate the missing digit.
Similarly, this would be safe, but not be as useful:
5555 5*** **** ****
Is there a well accepted pattern for storing partial credit numbers?
The Payment Card Data Security Standard states that if you are handling cardholder data, then you are subject to the constraints of the PCI DSS (which is very comprehensive and a challenge to comply with). If you want to store part of a card number, and don't want to have to deal with the Standard, then you need to make sure that a) you store NO MORE THAN the first 6 and last 4 digits; b) you don't ever store, process or transmit more than this. That means that the truncation has to be carried out before the data enters your control.
Given that you are talking about an ecommerce site, I think you'll have to deal with the PCI DSS sooner or later (since if you're not taking full PANs, you can't process transactions). Realistically, then, you should avoid storing more than the first 6 and last 4 digits of a PAN; the Standard then does not 'care' about this data, and you can store it in whatever form you see fit. If you store, say, the first 7 digits, then Requirement 3 of the Standard kicks in (and you start having to really understand key management in encryption).
I hope that this is of use.
March 2013 Edit:
A very pertinent resource is the PCI Security Standards Council, an organisation founded in 2006 by five of the biggest global Credit Card brands (AmEx, Visa, MasterCard, JCB International and Discovery) and which is the de facto authority on Security matters for the Payment Card Industry (PCI).
This organization publishes in particular the PCI Data Security Standard, currently in its version 2.0 edition which covers issues such as the management of complete or partial credit card numbers. This document if freely available but requires a simple registration and acknowledgment of license terms.
The following is the original, c. 2009 answer, mostly correct but apocryphal.
A common practice (whether legal or not I do not know) is to store the last 4 digits, as this may be used to help the customer confirm which of his/her credit cards were used for a particular transaction.
Without significantly improving the odds of a malicious person guessing the complete number, one can store the first 4 digits which are representative of the financial institution which issued the card, as mentioned in the question.
Do NOT, save many more digits than these 8 digits because otherwise, given the LUHN-10 checksum, you may provide enough info to make guessing the complete number more plausible (if still relatively hard, even with insight from the series used by a given issuer, in a given time period, but one should be careful...)
To make this whole thing safer, technically and legally, you may consider only storing such info if the customer explicitly allows it. You should also consider masking this info with a simple hash for storing in the database.
Also, what you can / should store following a particular transaction, is the transaction ID supplied by the Credit Card Processor, at the time the transacton is submitted. This ID is the key that allows locating most (all?) of the info you would even need, would there be any issue with a particular transaction. This type of info can typically be queried from a secure web site maintained by the Processing company, along with some aggregate reports which may include a grouping by card-type (Amex, Visa...) if that is why you are thinking of storing the first four.
If you don't need to store the whole credit card number, why do you need to store it at all? If you want to save the financial institution that issued the card, why don't you store the financial institution that issued the card?
Your specific question is answered in sec 3.3 of the PCI/DSS document.
First six and last four are max for display. Customer (paper?) receipts are more restrictive. Those with a legitimiate need to know can see full card data.
My recommendation is to contact your merchant provider and see what options are available to you. A number of the modern transaction gateways have "vault" features where sensitive information is stored at the provider and you simply reference customers by a token number when you want to bill them or check account information.
Along the same lines use of transaction specific tokens can be used to reference needed data stored on the providers system.
However I can't stress enough the importance of reading and understanding PCI DSS. Simply punting secure storage does not magically obsolve you from being subject to PCI compliance requirements!! This is only possible when your system never touches full card data.
The accepted pattern is don't store them at all.
In certain jurisdictions you may be breaking the law by storing them or any part of them.
You could instead, store a one-way (and therefore unrecoverable) hash of the credit card number.
The credit card companies have a standard for this. You'll probably find it buried somewhere in the terms of service of your payment processor that you will obey this standard. It answers you questions. You can find the standard here
Here in Canada, the usual way is to store the first 4 digit ( to identify the financial institution) and the 4 last digit to identify the credit card.
But be sure that you didn't break any laws.