I want to display the Card type used for apple pay transaction, I know that the card details are not present in Apple pay transaction, but is it possible to figure it out from PAN? or any other alternative?
I got something, where I get to know that your PAN is used to deduce your card type , so PAN is used as card number instead of the original card number. That's related to a specification form EMV saying applicationPrimaryAccountNumber is used to hide the actual card number from getting printed on your payment receipts.
So applicationPrimaryAccountNumber can be used to deduce the card type.
Hope this helps someone
Related
There is tag PAR(9f24) in documentation, but i don't see him when read application data from google pay. I just need to read pan. Is it possible detect who communicate with nfc reader?
For eg. Visa card, 9F24 is a part of DGI 0104, so if present you should be getting it in your READ RECORD 1, 4. Similarly you can check for other payment schemes.
If it is a wallet, it is a token(surrogate pan) you will receive instead of actual PAN. For a terminal it is as good as a pan that it can't differentiate whether it is a real pan or surrogate. PAN/Token you should be receiving in READ RECORD, Tag 57.
What do you mean by 'detect who communicate with nfc reader' ?
I am getting "INVALID. 4021 : The Card Range not supported by the system." in magento website while transaction. Please let me know how can I resolve this
The explanation is that Sage Pay do not recognise the BIN range for that particular card (identified by the first 9 or so digits of the PAN). This maybe because the number was input incorrectly, the BIN range is no longer valid (eg: card withdrawn), or the range is so new that Sage Pay haven't received and applied the updated ranges yet.
It looks like you need to unblock the card range. You can do this by clicking the “trashcan/rubbish bin” to the right of the card range. Once you have clicked the “trashcan/rubbish bin” you will simply be asked to confirm you would like to remove the card range from your blocked list.
Once you have confirmed you would like to remove this card range it will no longer appear in your blocked list and you can process transactions using this range.
If this does not fix it, check this out for more detail.
I am writing a point of sale application for a client who has some very specific needs. The client is a retail store, so when they process credit cards, they have a physical card present and can swipe it. The way it is now, at the end of check out, it presents the cashier with a total, and the cashier keys the total into a credit card terminal (by hand--it is not connected to the computer), swipes the card at the terminal and then when the payment is processed, the cashier presses the "Paid by Credit Card" and it prints a receipt.
The problem is that hand keying in totals is time consuming and prone to errors. I'd much rather have my program transmit the amount to a credit card terminal and then get a message when the transaction has been processed. I don't want to touch any card holder information (card number, etc) because I want to stay outside of PCI. All I want to do is send an amount and get back an "accepted" or "declined". You'd think this would be common, but I seem to have failed to find information. (For example, authorize.net's card present API requires me to collect and transmit the card number. I don't want to collect and transmit the card number. I want to transmit an amount and have someone else collect and transmit the card number and notify me when the process is complete.)
Does anyone have a solution for this? Has anyone worked with Verifone or Ingenico's hardware? I don't care if I'm sending the number of a physical terminal connected via USB or to a virtual software terminal. I just don't want to be the terminal myself, so that I'm not anywhere in the chain of card data.
I'm familiar with the VeriFone line of products, both signature capture (Mx900 series) and mobile iOS devices (Vx600). Your first hurdle is that the units are pricey for the little guy (ie: small business owner) at about $500 & $900 each respectively (retail).
On the bright side these things are your friends when it comes to PCI via what VeriFone dubs Verishield Protect (VSP). Essentially VSP encrypts the card swipe on the magstripe head and your POS solution will have to send out a decryption request which your POS software can either consume for settlement or for a fee VeriFone will send it directly to the bank.
The main sticking point of the PCI requirements I believe you're running into is the fact that the clear card data can't be "stationary" at any point in your code and either of these solutions will be a good launching point.
Good luck!
You should take a look at payworks. They provide a iOS / Android SDK to integrate a credit card reader. You never touch credit card data.
Disclosure: I am a software engineer at payworks.
The Pax S300 can do it, though I haven't found a processor that supports it. TSYS is supposed to, but after 4 months of run around, I could never get a device. Helcim has great customer service and report that they are planning an Ingenico solution for pushing the total to the terminal by the end of 2015.
Is it better to ask the user what type of credit card is being entered or to attempt to auto-detect card type using regular expressions?
Some online merchants ask for the credit card type explicitly (Visa, Mastercard, Amex, etc) in a drop-down menu. While others, including Amazon and GitHub, never ask explicitly and instead rely on the properties of the card to determine the card number.
One problem with relying on card type auto-detection is credit card regular expression patterns seem to need updating over time. So these regular expression patterns may need constant updating to remain accurate and prevent holes in the patterns.
Which is better, asking the user for card type explicitly or attempting to auto-detect card type? Are there other considerations?
I've done this kinda sfwr for 20 years and I still sometimes make the mistake of mis-marking my card when I place an order online. Then I get the error that the number I gave is not a VISA card. Silly, when it's so trivial for the programmer to attend to this and never show such an error to the shopper.
Paypal is the only major gateway that wants you to submit the card type with the transaction (I've never tested to see if they will return an error if you get it wrong). The shopper may get the card wrong as I sometimes do, but a regexp never will. If you are writing for any major gateway but Paypal anyway, you either won't be asked or the answer you furnish will be ignored.
Make the checkout process easiest on your shopper and your merchant happy with a speedier checkout. It's not going to have a material effect on the transaction.
Look closely at your gateway API - I'll bet they are not even asking - they can tell by looking at the card number.
One of the reasons they may ask for the credit card type is to provide with multi-part text input.
XXX - XXXX - XXXX - XXXX for American Express
XXXX - XXXX - XXXX - XXX for Enroute
XXXX - XXXX - XXXX - XXXX for Others
One may argue, it's more usable this way since the user gets a visual representation that matches the card. Also, it may be for hinting where to find the CSC (tho, that can also be inferred from the number).
I've got an eCommerce system that accepts Visa, Mastercard, Discover, and Amex for recurring billing. An issue we've run into is that in some instances, people have used pre-loaded gift cards rather than real credit cards, and once the balance runs out the recurring payment fails.
I'm trying to find a way to determine if a card number is a gift card or not. Is there any sort of unique characteristics to these credit card gift cards? Is there any way to tell from part of the Issuer Identification Number? We've already got validation to check the IIN and determine the card type, but I would expect the issuers use some set of digits to identify the prepaid cards.
I don't think you have a possibility to detect it from the card data you get from the user. The number is just an ID to identify the card in the issuer's database, and that's the location where such details are defined.