This question already has an answer here:
GETCHALLENGE issue(6D00) in EMV for MasterCard
(1 answer)
Closed 5 years ago.
In the case of GETCHALLENGE Request (0084000000), we are getting the positive response in the case of VISA\DEBIT card, but for AMEX and MASTERCARD we are getting the response as 6D00 (Instruction code not supported or invalid).
Not all instructions are supported by all card products. Different card products also support different transaction types, off the top of my head (so take my answer with a grain of salt) get challenge should online be necessary for offline transactions with asymmetric crypto where the terminal needs to identify itself to the card. It's possible (though not likely nowadays) that the card doesn't have a crypto coprocessor capable of handling this, so that code path is disabled. It's also possible that the MC and Amex EMV scheme specifics require a different transaction flow and you're not fulfilling the prerequisites for get challenge.
Without konw the sequence of commands you're sending to the card and the profile on the card, it's difficult to provide more information than the 6D00 is already providing.
Related
Closed. This question is not about programming or software development. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 5 months ago.
The community reviewed whether to reopen this question 5 months ago and left it closed:
Original close reason(s) were not resolved
Improve this question
I'm working on an application that is meant to distribute emails by the thousands. We've started interfacing with Mandrill to accomplish this.
So my coworker suggests that we use a subdomain to send all of theses emails out, so as to protect our top-level domain's reputation. We started squabbling about this because, as I argued, why would a simple subdomain protect our TLD, especially if they both resolve to the same IP address? If marketing.example.com is sending thousands of emails, aren't spam filters smart enough to know that they really originate from example.com?
So to clarify:
We're currently using Mandrill to distribute mail
We use DKIM to verify that the domain example.com is the originator of the message
Right now, we're only using one server to handle all this (plus Mandrill)
So how would switching the sender to marketing.example.com (with matching DKIM) help protect our TLD's reputation as a non-spammer? I don't understand, yet I've read articles to this effect, and he argues fervently that it's the right thing to do, yet no one can tell me how it works. I understand it from an organizational standpoint, but I don't understand how that protects our domain, unless spam filters really judge rep by the subdomain.
Can someone please help me piece this together?
Edit:
Here are some articles for reference:
Quora Question
LuxSci Blog
Mail Chimp Delivery - See page 11
Using a sub-domain will mitigate against the potential damage that could be done to your reputation by a miscreant user sending a campaign to a purchased list and using sub domains is considered best practice as per what you have read online.
In the first instance the big mailbox providers are not expecting to treat all mail sent from a domain in the same way. Google will want to classify your marketing messsages differently to notifications/transactional mail. One way to assist the mailbox providers in that task is to utilise sub-domains for different message types.
It is not about attempting to evade the spam filters, it is about providing meaningful and useful information through what most would consider proper utilization of rDNS. You are only mitigating because even if the BL operator or mailbox provider do assign separate reputations to each subdomain if sub-domains are being listed constantly then you do run the very real risk of having your TLD listed.
Spamhaus who operate one of the most widely used blacklists said this on the subject "It's a good way to convey in rDNS what is really happening within your network in terms of different customers sending different mailstreams. The risk is that "maindomain.com" may get filtered if too many subdomains look bad, but that needs to be a risk you accept and manage by maintaining the reputation of all subdomains."
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
Tasked to detail a simple API, I did a little research and suspect everything I know about the Internet is wrong.
I've Googled for far longer than I care to admit, reading a number of articles, StackOverflow questions and websites that all seem to vehemently disagree. I recognize every developer does things differently, but still suspect there is an official standard somewhere, or at least a general best practice (although, admittedly, not everyone follows whatever the best practice).
This API would use JSON. That I cannot change.
What my local peers do/have told me (very likely incorrect):
HTTP is a complex, antiquated beast that we should deal with as little as possible. It's simply a vehicle for moving chunks of JSON back and forth, where the magic happens. All data and metadata should be in the JSON, and you can set it up exactly as you like.
Use a 200 status code for everything, even if there is an application-level error or problem with the user's input. The other error codes mean something went wrong with the HTTP operation--a catastrophic unexpected server error, using the wrong URL, that kind of thing.
"Envelope" the JSON data for messages from the server; have JSON properties for metadata and include the actual JSON object/array inside a consistent property, like "data"
HTTPS is "nice to have" but not important for minor projects
Use PUT requests for everything
Log in to get a randomized strong of characters as an access token from the server. The server stores information on when the token expires, what account it is for and what IP address used it. Pass that access token to the server for every other call; the client does not store the password.
URLs tend to be verbs, like /register or /checkout or /changepassword. All other needed data is in the JSON. Each operation has its own URL
What I THINK might be right based on my reading, but not sure
HTTP is the divine data structure. Header information and server return codes can encompass any possible metadata and is, indeed, designed for that purpose. The contents need only contain the actual JSON object(s) the applications are acting upon. Put nothing in the JSON body that could possibly be part of the HTTP metadata.
ALWAYS use HTTPS, for everything
For any possible error (a form field didn't validate, the user's session expired, their game character is dead), send an HTTP status code. Try to pick what seems closest based on the W3C descriptions, but all that really matters is that you use it consistently in your system. The code should be enough to tell the client app what to do (show user validation errors and make them fix form input, make user log in again, take user back to main screen). The body, in case of errors, contains extra details about the error, if necessary.
The client app should pass login info with every request, in the HTTP header. This means it needs to use basic auth, which means it needs to remember the user's password.
The JSON data should never be in an "envelope". There is no standard format, because the contents directly represent the object(s) needed for the given operation as indicated by the combination of URL, GET/POST/PUT/DELETE
URLs tend to be nouns, like /user or /shoppingcart. Subdirectories of the URL refer to the object ID being acted on: /user/johndoe or /shoppingcart/12359. A URL could be used for different operations for GET (retrieve data) POST (update data) PUT (create new data) DELETE (remove data).
I'm not even sure that either of these is fully right--can you tell me the rules for what is the official, or most recommended way to structure such an API?
You should read the relevant part of the Fielding dissertation, that defines what REST is: http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm
Some additional dissertation from Markus: http://www.markus-lanthaler.com/research/third-generation-web-apis-bridging-the-gap-between-rest-and-linked-data.pdf He started the work about creating a standard REST implementation: the http://www.hydra-cg.com/ RDF REST vocab and the http://json-ld.org/ RDF JSON format. Currently we don't have a standard solution to describe the uniform interface of any REST service. This is like if we would not have a HTML standard. That's why we are not able to write REST browsers just application specific clients.
(Hydra is not production ready, I guess they'll need another 2-3 years to standardize it and start to build Hydra specific tools. Until then we cannot really talk about real REST, because most of the APIs define an implementation specific format or use a non-standard more or less common format, like HAL.)
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
I want to allow my customer users to enter their credit card information so that I can charge them every month.
I wonder how one should save this information?
Should it be saved in the MySQL database ("user" table) or is this kind of information too sensitive and need to be stored in another place?
I have no experience of this and would be glad if someone could advice me how to accomplish this.
Thanks.
As mentioned above, do not store credit card information in a database. It's a recipe for trouble. Doing so will make you a very attractive target for hackers and, if they are successful in retrieving them, end your business and potentially ruin your life as well as the lives of those whose credit card numbers are stolen.
Having said that, here are three things to consider:
1) Your best bet is to use a payment processor/payment gateway that offers recurring billing. An example of this is Authorize.Net's Automated Recurring Billing service. Once you set up the subscription they will automatically bill the user every month for you automatically and let you know the results of the transaction. It saves you a ton of work and relieves you of the liability of storing credit card information.
2) If you do store store credit card numbers you must follow PCI guidelines. These guidelines are set by the payment card industry and define what you can and cannot do. It also defines how credit card information must be stored. You will need to encrypt the credit card numbers and you should, but are not required to, encrypt related information (expiration date, etc). You will also be required for ensuring that your web server and network are secure. Failing to meet PCI compliance will result in losing your merchant account and being banned from having a true merchant account forever. That would limit you to using third party processors which are less flexible. Keep in mind that PCI guidelines are a good start but hardly a "how to" when it comes to online security. Your goal would be to exceed the recommendation (by a lot).
3) State and country specific laws supersede PCI compliance. If you suffer a breach and credit card numbers are stolen you risk criminal prosecution. The laws vary from state to state and are constantly in flux as lawmakers are only just beginning to realize how serious of a matter this is.
As far as encryption goes make sure you read up on which encryption algorithms are secure and have not been broken yet. Blowfish is a good start and if you use PHP the mcrypt library is recommended (example).
The safest way is to NOT store the credit card information on your system, but let a 3rd party payment provider do it for you.
It's not required that you use a 3rd party payment provider like PayPal, etc. – but you need to be PCI compliant if you are going to store payment card information. Read this article about BC Ferries, who face substantial fines for not keeping up to date with PCI compliance to grasp how serious it is to be PCI compliant.
My current employer is going through PCI compliance – it's not a trivial process, and requires staff for auditing. Enforcement depends on the country and state/province laws – Canada IIRC requires you to be PCI certified by a PCI employed committee, while some states in the US allow for PCI compliance auditing companies to serve in place of the PCI committee.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 12 years ago.
Improve this question
I am working on a payment form. What is that 3-digit code on the back of the card called? I can't find a consistent reference as to what to call it.
It is called the Card Security Code (CSC) according to Wikipedia, but has also been known as other things, such as the Card Verification Value (CVV) or Card Verfication Code (CVC).
The second code, and the most cited, is CVV2 or CVC2. This CSC (also known as a CCID or Credit Card ID) is often asked for by merchants for them to secure "card not present" transactions occurring over the Internet, by mail, fax or over the phone. In many countries in Western Europe, due to increased attempts at card fraud, it is now mandatory to provide this code when the cardholder is not present in person.
Because this seems to be known by multiple names, and its name doesn't seem to be printed on the card itself, you'll probably (unfortunately) still need to tell your users how to find the code - ie by describing it as the "3 digit code on back of card".
2018 update
The situation has not improved, and is now worse - there are even more different names now. However, you can if you like use different terms depending on the card type:
"CVC2" or "Card Validation Code" – MasterCard
"CVV2" or "Card Verification Value 2" – Visa
"CSC" or "Card Security Code" – American Express
Note that some American Express and Discover cards use a 4-digit code on the front of the card. See the above linked Wikipedia article for more.
You can't find a consistent reference because it seems to go by at least six different names!
Card Security Code
Card Verification Value (CVV or CV2)
Card Verification Value Code (CVVC)
Card Verification Code (CVC)
Verification Code (V-Code or V Code)
Card Code Verification (CCV)
It's got a number of names. Most likely you've heard it as either Card Security Code (CSC) or Card Verification Value (CVV).
Card Security Code
From Wikipedia,
The Card Security Code is located on the back of MasterCard, Visa and Discover credit or debit cards and is typically a separate group of 3 digits to the right of the signature strip.
On American Express cards, the Card Security Code is a printed (NOT embossed) group of four digits on the front towards the right.
The Card Security Code (CSC), sometimes called Card Verification Value (CVV or CV2), Card Verification Value Code (CVVC), Card Verification Code (CVC), Verification Code (V-Code or V Code), or Card Code Verification (CCV)[1] is a security feature for credit or debit card transactions, giving increased protection against credit card fraud.
There are actually several types of security codes:
* The first code, called CVC1 or CVV1, is encoded on the magnetic stripe of the card and used for transactions in person.
* The second code, and the most cited, is CVV2 or CVC2. This CSC (also known as a CCID or Credit Card ID) is often asked for by merchants for them to secure "card not present" transactions occurring over the Internet, by mail, fax or over the phone. In many countries in Western Europe, due to increased attempts at card fraud, it is now mandatory to provide this code when the cardholder is not present in person.
* Contactless Card and Chip cards may supply their own codes generated electronically, such as iCVV or Dynamic CVV.
The CVC should not be confused with the standard card account number appearing in embossed or printed digits. (The standard card number undergoes a separate validation algorithm called the Luhn algorithm which serves to determine whether a given card's number is appropriate.)
The CVC should not be confused with PIN codes such as MasterCard SecureCode or Visa Verified by Visa. These codes are not printed or embedded in the card but are entered at the time of transaction using a keypad.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 3 years ago.
Improve this question
Our motor pool wants to scan drivers’ licenses and have the data imported into our custom system. We're looking for something that will allow us to programmatically get the data from the scanner (including the picture) and let us insert it into our application. I was wondering if anyone has had experience with this type of system and could recommend one or tell us which ones to avoid. Our application is written in PowerBuilder and uses a DB2 database.
Try solutions by idScan.net (www.idScan.net)
There is SDK that will allow drivers license parsing for all states in the USA and Canadian provinces. You can also purchase hardware such as ID scanner E-seek m250 that reads both 2D barcode and magnetic stripes (software is included).
Good luck!
We support something similar in our records management software. Our application is designed to work with a wedge reader, since they are the easiest to get up and running (no special drivers needed). When a card is swiped, the reader sends keystrokes to the OS for each character that is encoded on the magnetic stripe, with a simulated Enter keypress between each track (an AAMVA-compliant license has 3 data tracks).
It's slightly annoying because it behaves exactly as if someone was typing out the data by hand, so there is no easy way to tell when you have all the data (you could just wait to get 3 lines of information, but then it's difficult to detect invalid cards, such as when someone tries to swipe a student ID card, which might have fewer than 3 tracks encoded; in this case, the application hangs forever waiting for the non-existent third track to be received). To deal with this, we use a "fail-fast" approach: each time we get an Enter keypress, we immediately process the current line, keeping a record of which track we are expecting at that point (1, 2, or 3). If the current track cannot be processed (for example, a different start character appears on the track that what is documented for an AAMVA format driver's license), we assume the user must have swiped something other than a driver's license.
I'm not sure if the reader we use supports reading image data or not. It can be programmed to return a subset of the data on the card, but we just use the factory default setting, which appears to return only the first three data tracks (and actually I believe image data is encoded in the 2D barcode found on some licenses, not on the magnetic stripe, but I could be wrong).
For more on the AAMVA track format that is used on driver's license magstripes, see Annex F in the current standard.
The basic approach we use is:
Display a modal dialog that has a hidden textbox, which is given focus. The dialog box simply tells the user to swipe the card through the reader.
The user swipes the card, and the reader starts sending keydown events to the hidden textbox.
The keydown event handler for the textbox watches for Enter keypresses. When one is detected, we grab the last line currently stored in the textbox, and pass it to a track parser that attempts to parse the track according to the AAMVA format.
If this "fail-fast" parsing step fails for the current track, we change the dialog's status message to a message telling the user the card could not be read. At this point, the textbox will still receive additional keydown events, but it's OK because subsequent tracks have a high enough chance of also failing that the user will still see the error message whenever the reader stops sending data.
If the parsing is successful, we increment a counter that tells the parser what track it should process next.
If the current track count is greater than 3, we know we've processed 3 tracks. At this point we parse the 3 tracks (which have already split most of the fields up but everything is still stored as strings at this point) into a more usable DriversLicense object, which does additional checks on the track data, and makes it more consumable from our application (converting the DOB field from a string into a real Date object, parsing out the subfields in the AAMVA Name field into first name, middle name, last name, name suffix, etc.). If this second parsing phase fails, we tell the user to reswipe the card. If it succeeds, we close the dialog and pass the DriversLicense object to our main application for further processing.
If your scanner is "twain compliant", You will then be able to manage it from your app through an ActiveX control you can buy on the net like this one. You'll be able to manage your basic scan parameters (quality, color, single/multiple pages can, output format, etc), start the scan from your app, save the result as a file and transfer this file wherever needed. We have been using it with VB code for the last 2 years. It works.
Maybe you want to use magnetic stripe reader, to get driver license info from the card. As I remember most of the Driver licenses just have the data in plain text on those stripes, so it is relatively stright forward programming-wise.
MagStripe readers are also cheap now days.
You can try something from this list: http://www.adams1.com/plugins.html
I have not used them myself, though.
I wrote a parser in C#, and while it's "ok" it's still far from perfect.
I can't seem to find it but a Wikipedia entry used to exist that has the patterns to look for (trust me, parsing this yourself is a pain without any help).
Be aware that different states have different laws for what you can and can't use government issued ID's for. Texas has one.
We use a dell card reader and it inputs it exactly as though it were being typed through a keyboard, followed by the enter key. This made programming /very/ easy because then you just send focus to the text box and wait for enter. The main keys which break it in to chunks is the carrot '^'. Break that and you'll have your basic chunks.
You can also use InfoScan SDK. You can find it on www.scan-monitor.com the system allows you to use any scanner and does not make you purchase a specific scanner.