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.
Related
I'm aware of the Luhn algorithm for validation of payment card numbers.
However, is there something similar that will tell me whether a particular card requires a start date or issue number, as these aren't universal?
Using this information, I would then show or hide the start date and/or issue number input boxes once a customer has entered their payment card number.
As far as I know, no there is no way to detect whether the expiry date (I assume that's what you meant by start date) is required based on the card number.
In these kind of situations (i.e. special cases for different cards), I've turned to this site as well as the backing data. With this data, you can get the bin of a credit card from the first 6-8 digits. I'm skeptical as to whether even the bin contains the data you are looking for, but good luck!
Just a note: be wary of the data since it is open source. In my experience it has been accurate, but make sure you keep that in mind. There are enterprise solutions to get bin data if accuracy is that important to you.
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
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'm using cform to capture internet leads on my website. I need a code so that people have to provide full 10 digit phone number or else it wont let them submit the request. Thank you.
Just get the length of what the user provides. check if they are all numbers, and if they are, assume that it is a number.