Slashdot Mirror

(I work for First National Merchant Solutions, a company which helps businesses accept payment by credit card.)

Many highly-moderated posts here are confusing the facts, or saying how they think the system should work.

The merchant SHOULD keep track of the credit card number. They can't print the card number on receipts they give to their customers, but the card number is sometimes the only customer identification they have. If a chargeback or retrieval request comes through, the mechant needs to be able to find information about a specific sale, and they usually find that using the card number.

Someone reported that a business issued a credit to their card without requiring their card number again. This, too, is normal. Even if the merchant didn't store the credit card number, they would only have to call their credit card processing company (like the company I work for), identify themselves properly, give them the day of the original sale and the amount, and WE would tell them your card number and expiration date so they could process the credit. (You would have been wasting that manager's time, if you did talk to them.)

Visa and Mastercard regulations prohibit merchants from storing the CVV2/CVC2 number (that's the 3 digit number printed on the papery stripe on the back of your card), or any of the 'secret' information encoded on the magnetic stripe of the card. Everything else they can store, AS LONG AS THEY COMPLY WITH SECURITY REQUIREMENTS. http://usa.visa.com/business/accepting_visa/ops_ri sk_management/cisp.html If they maintain a secure system, there is no problem at all with them storing their customers' details.

If there's a security breach, the government's intervention is not required. Processing regulations already demand fines for noncompliance. If a merchant's security is penetrated and they lose a bunch of customer details, they'll have to pay a fine and have their security audited to Visa/Mastercard's satisfaction. These fines scale according to the size of the merchant and their annual transaction volume. The largest merchants (like those many of you are talking about) could face huge fines in the hundreds-of-thousands-of-dollars range, if they're noncompliant and they stay that way for any length of time.

If a merchant is using your card information in a way they shouldn't (for example, assuming you'll put your sale on a card you used last time) that's a customer service issue. If they actually charge your card unauthorized, make them give the money back. If they don't credit your account within 30 days, contact your issuing bank. Chargeback reason "Fraudulent Transaction - No Cardholder Authorization." They aren't actually breaking any rules by using a stored card number, but that's still a pretty dumb thing to do if you want happy customers.

OK, now back on topic. Pin-based debit information, like full magnetic stripe info and ESPECIALLY any information about the pin number challenge/response, should NEVER be stored by any merchant. (They can store the card number, debit network ID, various transaction reference numbers, etc.) If someone's software is doing that, merchants should stop using that software. Maybe Visa/Mastercard should release a bulletin to its member organizations, for its merchants, warning them that if they're using this software they need to stop. (Looks suspiciously like something which inspired the original article, doesn't it?) If merchants fail to switch to other, compliant software versions, they deserve the fines and sanctions they'll incur.

(How can Visa and Mastercard levy fines, if they're not the government? Contract law. Visa and Mastercard require contracts with processing companies, like the one I work for. When we sign on a new merchant, they must sign a merchant processing agreement, which binds them to Visa/Mastercard's regulations, and with that binds them to any fines they might incur.)

Now let's get the discussion back on track. No more of this "businesses are storing my credit card number and I don't like it!" stuff.

Not regulatory as in government, but industry regulated yes. All card brands require that you comply with the Payment Card Industry, Data Security Standard. http://www.visa.com/cisp for more info...

Yes, lets put more lawyers to work. Visa has already led an initiative to make credit card usage more secure, it's called CISP, Cardholder Information Security Program. You can find information here: http://usa.visa.com/business/accepting_visa/ops_ri sk_management/cisp.html

All retailers and software providers must comply with this initiative if they want accept Visa cards as payment. Having worked in the retail POS software industry for the last 11 years I have seen all sorts of non-complient behaviour. Just because someone passes a law or publishes a standard doesn't mean that everyone is following said law/standard. Everyone stores your card information at some level or another.

It appears theres a clause for Debit cards used at ATM's... http://usa.visa.com/personal/security/visa_securit y_program/zero_liability.html Extract from above Link: The Zero Liability policy covers all Visa credit and debit card transactions processed over the Visa network--online or off. The only transactions not covered under the Zero Liability policy are commercial card, ATM, and non-Visa-branded PIN transactions.

To Quote "CISP compliance is required of all merchants and service providers that store, process, or transmit Visa cardholder data. The program applies to all payment channels, including retail (brick-and-mortar), mail/telephone order, and e-commerce. Compliance with CISP means compliance with the PCI Data Security Standard with the required program validation. The Payment Card Industry (PCI) Data Security Standard offers a single approach to safeguarding sensitive data for all card brands. Other card companies operating in the U.S. have also endorsed the PCI Data Security Standard within their respective programs." Everything you wanted to know about Visa's Cardholder Information Security Program.

Apparently the Boston Globe Doesn't comply with the Payment Card Industry standard, found here: http://usa.visa.com/business/accepting_visa/ops_ri sk_management/cisp.html
Specifically these sections:
9.10 Destroy media containing cardholder information when it is no longer needed for business or legal reasons:

9.10.1 Cross-cut shred, incinerate, or pulp hardcopy materials

9.10.2 Purge, degauss, shred, or otherwise destroy electronic media so that cardholder data cannot be reconstructed

1. EU law is not applicable in the US, if it is really even EU law (since you don't seem able to look up even the simple US EBay policy) at ebay.com.

2. Visa completely prohibits payment surcharges in the US. There are any number of references to this on the Visa site and all over the internet for anyone willing to look:
http://usa.visa.com/download/business/accepting_vi sa/ops_risk_management/rules_for_visa_merchants.pd f
http://usa.visa.com/download/business/accepting_ visa/ops_risk_management/visa_risk_management_guid e_ecommerce.pdf
Search for the word 'surcharge'. Trivial to find thousands of internet documents explaining this fundamental policy of Visa and other credit cards.

3. EBay prohibits payment surcharges. http://pages.ebay.com/help/policies/listing-surcha rges.html

4. The seller would have to mention the surcharge in his listing, which he clearly did not either before or after the dispute when he claimed to accept credit card as an alternative to PayPal, because adding unexpected surcharges is wrong.

5. I tried and tried to get anyone to look at it. They are all complicit in the fraud because they would not. No one ever challenged that I had EBay, Visa, etc. policy on my side. They just completely ignored it, except when the Seller complained with no evidence (and I had already submitted multiple evidence that he would not sell), they jumped to issue a strike on me.

6. I would take you up on looking into it further if I did not consider it only a PR ploy to pretend to take it private because we happen to be in a public forum where EBay is getting a very justified black eye by many with similar experiences. Lack of trying for resolution on my part was never an issue at the time, and the records are long erased by now because in disgust I went through the multi-month process of having my username removed.

7. The much better thing you could do is try establish a credible system for getting responses and getting this sort of issue resolved, but you will be working against EBay's status quo. Until then, eBay will be fraud's best friend, punishing only the victims, and I will hold a discussion with EBay only in a public forum where their lies become more transparent, and I will continue to state that one of the most-effective ways to avoid fraud on the internet is adding -EBay to searches.

Try looking up your own EBay policies before responding. Are you really an EBay employee, or are you just trying to make them look bad? I accept the possibility that you may be honestly deluded about EBay status quo, but you are not trying at all. It was prominently linked from the first page on policies for sellers at ebay.com.

Visa CISP really isn't a bad thing. It's basically an exercise in prudence -- if you protect their data in an appropriate fashion, you'll be less likely to be smeared over the front page of the Wall Street Journal as the latest victim of a data thief. That kind of negative publicity is hard to recover from, and expensive, too.

Anyway, here's what Visa expects of you: this page is instructions for small businesses and merchants on how to be CISP compliant. There's a link there to a PDF. But even here, it says "Maintain an Information Security Policy". It doesn't define the policy, it just says you have to have one and maintain it.

PCIDSS -- Payment Card Industry Data Security Standard.

http://usa.visa.com/download/business/accepting_vi sa/ops_risk_management/cisp_PCI_Data_Security_Stan dard.pdf

If you are a processor of Visa and/or MasterCard transactions (not a merchant, but a financial institution or payment processor) then it applies. It's got differing levels of compliance required depending on the volume of transactions processed -- a small processor has a lower bar than, say, First Data Corporation, one of the (if not the) largest payment processor.

It's similarly light on the implementation details -- which means there's plenty of good money to be made by consulting/auditing firms.

Eh? Nice link, but you didn't really read it I guess. I have seen PCI compliance many times which required truly comprehensive standards for IT security, and the use of a certified vendor like Teros, as well as a (quarterly) inspection by a certified inspection service and many other things. Picture an 80-item questionare where every answer has to be yes. And these are orgs with stellar fraud/CB stats.

I don't know what level you are. You may have lesser requirements if you don't have that much volume...

You might want to either do some reading in advance, or be a little more circumspect next time...

You're HIGH if you think that companies handling credit card transactions are *required* to use an application level firewall... PCIDSS Section 1.1 requires a FIREWALL... and that's it... I've been through a PCIDSS audit and a stateful packet inspection firewall will pass just fine...

No he wont. Not for the reasons you're implying anyway. A little known company called Visa manages to keep all their IT guys in cubes. If you think your IT guys deal with a lot of financial information...

It's all about using the correct procedures in handling that financial info. This means, lock your desktop when you leave to take a piss, and secure all your hardcopies in a lockeable cabinet at the end of the day. What exactly are the 4 walls of an office affording you that a locked cabinet cannot?

Comply with Visa/MC's PCI (pdf warning):

http://usa.visa.com/download/business/accepting_vi sa/ops_risk_management/cisp_PCI_Data_Security_Stan dard.pdf?it=search

If its information that you don't think someone who gets a backup tape should be able to read, then you better encrypt it.

At a minimum, you should look at encrypting all the account numbers, ssn's, credit card numbers, and the like. Encrypting text data -- such as names and addresses will likely impose a significant usability performance on your system.

Unsigned Cards
While checking card security features, you should also make sure that the card is signed. An unsigned card is considered invalid and should not be accepted. If a customer gives you an unsigned card, the following steps must be taken:
  Check the cardholders ID. Ask the cardholder for some form of official government identification, such as a drivers license or passport. Where permissible by law, the ID serial number and expiration date should be written on the sales receipt before you complete the transaction.
  Ask the customer to sign the card. The card should be signed within your full view, and the signature checked against the customers signature on the ID. A refusal to sign means the card is still invalid and cannot be accepted. Ask the customer for another signed Visa card.
  Compare the signature on the card to the signature on the ID. If the cardholder refuses to sign the card, and you accept it, you may end up with financial liability for the transaction should the cardholder later dispute the charge.

See ID Some customers write See ID or Ask for ID in the signature panel, thinking that this is a deterrent against fraud or forgery; that is, if their signature is not on the card, a fraudster will not be able to forge it. In reality, criminals dont take the time to practice signatures: they use cards as quickly as possible after a theft and prior to the accounts being blocked. They are actually counting on you not to look at the back of the card and compare signaturesthey may even have access to counterfeit identification with a signature in their own handwriting. See ID or Ask for ID is not a valid substitute for a signature. The customer must sign the card in your presence, as stated above.

Requesting Cardholder ID
When should you ask a cardholder for an official government ID? In most cases, merchants may not ask for an ID as part of their regular card acceptance procedures, either when a valid card is first presented or to complete a sale. Laws in several states also make it illegal for merchants to write a cardholder's personal information, such as an address or phone number, on a sales receipt.

You may ask for an official government ID or other personal information whenever you are suspicious about a card or a transaction. If the cardholder refuses the request or you are still suspicious, make a Code 10 call.

See Visa's own website, specifically the section regarding "Unsigned cards"

http://usa.visa.com/business/accepting_visa/ops_ri sk_management/card_present.html

  If the card has a "See ID" in place of a signature...
http://www.usa.visa.com/img/other/card_see_id.gif
      1. Request a signature. Ask the cardholder to sign the card and provide current government identification, such as a driver's license or passport (if local law permits).
      2. Check the signature. Be sure that the signature on the card matches the one on the transaction receipt and the additional identification.

  If the card has a "See ID" in place of a signature...
http://www.usa.visa.com/img/other/card_see_id.gif
      1. Request a signature. Ask the cardholder to sign the card and provide current government identification, such as a driver's license or passport (if local law permits).
      2. Check the signature. Be sure that the signature on the card matches the one on the transaction receipt and the additional identification.

Two Factor Authenticationis not the only part of the problem. It does helps a lot for strong authentication of the client. Some other important parts of the problem are:

1. Mutual Authentication. Short term, need to have the FI display something unique which helps the user tell for sure they are connected to who they think they are connected to. Longer term, need changes to Firefox and IE6 (which for me means 95% of my customers) so that the PKI credentials for the FI are displayed.
2. Need to be able to ask the client if I can query their computers status, and make sure that they have a current patch level and decent AV and Spyware protection. So, need to ask Linux and Windows (or other products installed on Windows and Linux) to provide capabilities, because I do not want to download code. After all, not my business. Could request this function with a special HTTP header.
3. Mid term to long term, I love the idea of a second factor (USB attachment) which supports PKCS#11 / PKCS#15. This, along with #1, prevents MITM attack.
4. Everywhere in the world, except maybe theU.S., we are rapidly rolling out EMV and VIS. So, we are going to have Smartcards in everyone's wallet, that will be a key part of the 2FA problem. Just need a small portable USB device to support a USB interface to the card. So far, I am having trouble with this, need something small enough to hang on your keychain. Wait a year or so, someone will build it.

On the server side, need to make some changes as well.

1. Proper support for tiered authentication. So, you can access less dangerous functionality with less authentication
2. Base the entire thing on a decent RBAC approach, so I can administer and keep track of what is going on. Note, DSD gives me a decent way to model tiered authentication.
3. Need to build a proper authorization framework so that the requirements for both a proper authentication tier and even a signature (OTP, Digitial Signature) on specific transactions can be enforced.

The bottom line:

1. The stronger the authentication of the client, the better. As we move towards 2FA, lets be careful to not make any stupid biometric decisions. Biometrics should only be used to gain access to the hardware second factor, for instance via a thumbprint. Then, it the second factor gets stolen, we just revoke the token; we do not need to cut off your thumb!
2. Mutual authentication. Not only does the client need to prove who they are, the FI needs to prove who it is. Some cool stop-gate things with GIFs and stuff are possible, but in the middle and longer term, changes to the browsers (the two that dominate my customer base are Firefox and IE)
3. Assurance the PC is protected. If you will excuse me the vanity, I will riff on "Clarke&'s Third Law", name it "Cameron's Law&", and state that "Any sufficiently infested PC cannot be protected from allowing the customer to be scammed". Frankly, I was really hoping that the Fed would step up to that in its

Not quite, but there is a mandatory audit procedure enforced, if you are a large enough merchant.

Any hotel chain that does this is in violation of the Visa Payment Card Industry Data Security Standard. Notably Sections: 3.4 .."Render sensitive cardholder data unreadable anywhere it is stored (including data on portable media, backup media, in logs... Requirement 4: Encrypt transmission of cardholder and sensitive information across public networks. Requirement 9: Restrict physical access to cardholder data Any physical access to data or systems that house cardholder data allows the opportunity to access devices or data, and remove systems or hardcopies, and should be appropriately restricted. Note that these Payment Card Industry (PCI) Data Security Requirements apply to all Members, merchants, and service providers that store, process or transmit cardholder data. Additionally, these security requirements apply to all "system components" which is defined as any network component, server, or application included in, or connected to, the cardholder data environment. Violations of the Visa PCI Security Standard can result in the institution being fined and potentially losing the ability to process future credit card transactions. Fines are generated when an audit of theft of information shows non-compliance by the company. Fines range into the hundreds of thousands of dollars. The PCI Data Security Standard has been adopted by Visa/Mastercard and in similar forms by Discover and American Express. I wonder where the PCI auditors are with checking for this. Anyone who wants to catch up on the Visa PCI Data Security Standard can do so here: http://usa.visa.com/business/accepting_visa/ops_ri sk_management/cisp.html

Yikes, Rabbar!

I've had "Please ask for ID" on my cards for yrs. Only rarely (1 in ~50 times?) am I asked for my ID, and I've never had an experience that looks like sales personnel know about Visa's policy you've documented. (When a clerk does ask, I thank her or him.) So, I checked the Visa Web site and confirmed you correspondence:

Some customers write "See ID" or "Ask for ID" in the signature panel, thinking that this is a deterrent against fraud or forgery; that is, if their signature is not on the card, a fraudster will not be able to forge it. In reality, criminals don't take the time to practice signatures: they use cards as quickly as possible after a theft and prior to the accounts being blocked. They are actually counting on you not to look at the back of the card and compare signatures--they may even have access to counterfeit identification with a signature in their own handwriting. "See ID" or "Ask for ID" is not a valid substitute for a signature. The customer must sign the card in your presence, as stated above.--[Visa PDF for merchants]

So, there appear to be two problems:

1. Clerks don't look at the sig space on cards, and
2. Clerks don't implement card companies' policies.

I feel so much less secure now. My $$ is safe, no? Mayhaps I should sign with the PW for my PayPal account? Nahhh, that changes more frequently than the cards are replaced.

Are any of you other guys working on Payment Card Industry Data Security Compliance? (PCI DSS)

Check this out:

The full requirements are here

Check out section 10 and the requirements for logs. Note the suggestion to store logs for 1 year with high security, possibly online.

Does anyone know of any online backup service that would fit the bill for this?

http://www.visa.com/cisp

Read and enjoy. Deadline is the 30th of this month.

Essentially they are just that: best practices. I just did an audit prepping a company for Visa CISP certification and most things they require are pretty standard like password complexity, physical security, encryption used over public links, etc.. However the security all revolves around the credit card number so it's a little more focused than a normal security gig.

Also, Visa/Master require that vendors store as little info as possible in as few places as possible, and that they encrypt it in storage. Specifically no one is EVER supposed to store the CVV/CVC code or any portion of the magnetic stripe info. Also specific to this set of requirements, a subpoint of it being CC#-centric, is that even non-mission-critical systems have to have the same high level of security if they store CC info. So no one gives a shit if you are doing "research" or just processing sales, you HAVE to protect the numbers, ideally by encrypting that field in Oracle or something equivalent so when FedEx loses your backup tape it isn't a disaster.

One last caveat is that the program is still ramping up. It started about 4 years ago but most companies are struggling to implement the reqs still, and Visa is very understanding since if they are too stringent and cut off the offending vendor they lose revenue.

CISP and PCI compliance

If data in a vendor's system is compromised, Visa and Mastercard will charge fines upward of a hundred thousand dollars per violation, and by the time a third violation occurs, your place of business may be denied use of credit card services permanently.

That's a good thing for everyone, but when crap like this happens it pisses me off. Credit Card companies are (correctly) requiring the strictest standards for storing cardholder data by vendors, but at the same time they themselves are losing 40 million cardnumbers, losing unencrypted backup tapes in shipping, etc. What pisses me off is that if I screw up and lose a credit card number into the wild, I get fined 100K. If they lose 40 million cards, what are they gonna do, fine themselves?

I doubt a lawsuit will prevail unless the folks whose info was compromised can show damages resulting from this.

With the VISA/CISP http://usa.visa.com/business/accepting_visa/ops_ri sk_management/cisp.html and Payment Card Industries (PCI) programs in place, the processor will undoubtably be fined a nice amount of money.

I work for a credit card payment processor (not the one in question), so I can speak to this directly:

Visa and other credit card companies have recently been getting VERY demanding regarding security practices. They have literally forced everyone that processes payments for them to secure their networks, or face losing their processor license, and with it, all of the customers that use Visa.

The security requirements are part of a new program called CISP (Cardholder Information Security Program), which requires safeguards that are at least as demanding, if not more so, than federal reserve requirements for banks. You can read more about CISP here.

Some of these requirements are:

- All cardholder data is encrypted whenever stored.
- Firewalls need to protect perimeter networks (of course).
- All passwords used by sysadmin or developers need to be changed on a regular basis, and must adhere to strict guidelines about length and password strength. This forced us to deply LDAP.
- OS level auditing must be turned on, and all employee access to any cardholder data must be audited and stored in a secure location.
- All hosts on the network must be scanned regularly using Nessus or other commercial scanning tools.
- Security patches must be applied regularly, based on the results from the scans.
- Intrusion Detection Systems must be installed on the network.
- No insecure protocols can be used such as telnet, rlogin, etc. All communication must be secured using SSH or some other type of encryption.
- There are also a ton of safeguards to prevent developers from sneaking malicious code into production systems (ala Office Space). No one developer can modify code without another developer signing off on it, and a security officer approving the code before it is released from development to QA, and from QA to production.
- Different teams of developers work in Dev, QA, and Production in order to prevent any one team from being able to hack the system.

This all adds up to millions in extra costs for the credit card processors. It has been a huge burden on the industry. These safeguards are a good idea, but the problem is that the credit card system is only as good as it's weakest link. The company I work for might be as secure as humanly possible, but because some processor that's a hell of a lot bigger than us in Arizona got hacked, the security at my company does those people no good.

Anyway, I'm posting this anonymously so you can't tell where I work at.

Here is the credit card companies "BIBLE" in regards to security... Payment Card Industry Data Security Standard: http://usa.visa.com/download/business/accepting_vi sa/ops_risk_management/cisp_PCI_Data_Security_Stan dard.pdf

A merchant must not refuse to complete a MasterCard card transaction solely
because a cardholder who has complied with the conditions for presentment
of a card at the POI refuses to provide additional identification information,

Not for long, they are trying to make these type of scans manditory, if you handle Credit Card information at all. This includes all those Mom and Pop hosted sites too.

You ALWAYS have to sign a credit card.
http://usa.visa.com/business/accepting_visa/ops_ri sk_management/card_present.html#anchor_5

Really? So why this, then? (This has been previously linked to in the discussion above.)

In particular, check out Step #6 of "Quick steps to Visa Card acceptance":

6. Check the signature. Be sure that the signature on the card matches the one the transaction receipt.

I think it's a great idea, and that's what I do, but, at least according to VISA, it's not valid.

The correct procedure, according to VISA, is to ask them to sign the card right then.

Quicker than making a trip to the ATM, more convenient than writing checks, and safer than carrying cash.
http://usa.visa.com/personal/cards/debit/

http://usa.visa.com/business/accepting_visa/ops_ri sk_management/card_present.html

So, sign it, then add "See ID". The signature IS there for verification, and good clerks will request the ID. If they're really sticklers, then just sign the slip with the "See ID" in your signature and claim that that IS your signature!

This is not true.

http://www.usa.visa.com/business/accepting_visa/op s_risk_management/card_present.html?it=c%7C/busine ss/accepting_visa/ops_risk_management/index.html%7 CCard-Present

(-1, Factually Incorrect) Standard operating procedures straight from VISA USA.

Not according to their website. http://www.usa.visa.com/business/accepting_visa/op s_risk_management/card_present.html?it=c%7C/busine ss/accepting_visa/ops_risk_management/index.html%7 CCard-Present

Sorry, you're completely wrong. That is what the signature is there for, at least according to Visa. http://www.usa.visa.com/business/accepting_visa/op s_risk_management/card_present.html?it=c%7C/busine ss/accepting_visa/ops_risk_management/index.html%7 CCard-Present

It was absolutely the right thing to do, as another poster noted above. There was a guy in our local paper who wrote an angry letter to the editor, blasting the local BMV for not taking his "SEE ID" credit card. I wrote back the next day and advised him to stop embarassing himself in public...

That's a lie Clark Howard has been spewing for years. See:

http://usa.visa.com/personal/security/zero_liabili ty.html?it=il%7C/personal/cards/debit/visa_check_c ards_faq.html%7CZero%20Liability

The Zero Liability policy covers all Visa credit and debit card transactions processed over the Visa networkonline or off.

The card is required to be signed for the transaction to be completed to ensure that you have agreed to the cardholder contract.

Like many things, if you don't understand them, they're quite easy to mock. In this case, the policy for an unsigned card is to make the customer sign it and then sign the receipt and compare the two.

When that is completed, the merchant can rest assured that the customer has agreed to the cardholder agreement and agreed to the terms on the receipt provided by the merchant.

A lot of people have talked about writing "See ID" on the back of the card for the merchant to check. I've dealt with this before, and if the merchant is following the proper procedures (visa here), they should make you sign the card before they will accept it. The US Postal service will not accept it at all.

So this should only be a one-off for people who do it, although from my experience and most of the reports here it seems that very few places follow through on this even if they check.

As for the main question, are the sigs useless? Well no, they're not foolproof but act as a line of defense which makes fraud a bit harder, puts off some people from trying it and maybe gets some fraudsters caught.

She politely asks him to sign his card so she can compare signatures. It took him a beat to process the fact that "Yes she's that dumb.", he signed the card, she checked the sigs. and let him be on his merry way.

Nothing to do with being dumb. A credit card is not valid until signed (it says this by the signature panel on all my Visa and MasterCard cards, though interestingly not on my Discover), and she did exactly what card issuers require merchants to do when presented with an unsigned card.

When I used to cashier part time in college I always wished I could reject those cards. "Sorry, SEE ID isn't the cardholder's name. I can't accept this."

Maybe policy has changed, but currently that is exactly what you are supposed to do. An unsigned credit card should not be accepted.

No, in practice, debit cards are not covered by the zero liability plan. From VISA's site:

*Covers U.S.-issued cards only. Visa's Zero Liability policy does not apply to commercial card or ATM transactions, or to PIN transactions not processed by Visa. See your Cardholder Agreement for more details.

**Cardholders should always regularly check their monthly statements for transaction accuracy. Financial institutions may impose greater liability on the cardholder if the financial institution reasonably determines that the unauthorized transaction was caused by the gross negligence or fraudulent action of the cardholder--which may include your delay for an unreasonable time in reporting unauthorized transactions.

Before you think 'I can keep my PIN secret, so what's the problem?', try to figure out how a transaction was processed by looking at your bank statement. Was it credit or debit? What network processed the transaction?

I recently had my VISA card used fradulantly, and was stuck footing the bill.

The 'call this number if your card is lost or stolen' number on the back of the card didn't work. Apparently, the organization that I contacted does not handle debit cards.

The charge was for $40; the zero liability plan applies to the first $50 of fradulant transactions.

Of course, my bank "didn't know" how the charges were made, and ATM/pin transactions are not covered, so I couldn't take advantage of the Zero Liability policy without paying the bank to figure it out for me.

I found that the vendor (McAfee) was totally unresponsive (I never managed to contact a human being after trying for a few hours), so I could not obtain any information about the transaction (I thought I would get an IP address or a shipping address. Yeah, right!)

The bank wanted to charge well over $100 to 'launch an investigation', which would be billed as an initial cost plus an hourly fee, and could drag on indefinitely.

VISA charges vendors a few percentage points of every purchase you make. If the per-transaction fees aren't being used to combat fraud on the network, or even to maintain contact information for a handful of major vendors, what are they for?

If the average amount of a transaction is $5, and Visa takes 1% (two very low estimates), that's costing the vendor $0.05. For what? Sending a few kilobytes of data over an encrypted line? Running a (really expensive!?!) database transaction?

I've been dumping around a bit over 1% of my income into this network for years. If federal tax is 20%, that's roughly as much as I've put into the department of education and department of transportation, combined!

At this point, I think I'll just carry cash, since its less of a hassle. If I get mugged, I'm out $100, and that's it. With a VISA card, I get to negotiate with my bank over who is liable for what, and there is a huge risk of electronic fraud. Besides, using cash keeps prices lower, and most businesses are happy to accept it.

Visa debit cards are covered under their 'zero liability fraud' policy. They've been advertising it pretty heavy lately with that lady in the parking lot that has all the super heros come to her rescue. lame. http://usa.visa.com/personal/security/zero_liabili ty.html/

One of the biggest values of such a solution has to do with Micro-Payment. How many times have you turned away from a drive-through because the lineup is too long. This class of business needs to be able to process an order (including settlement) quickly. The more orders they can put through in an hour, the more revenue the business generates.

Typically, this sort of transaction will also be done offline. This will allow the business to batch process their transactions at the end of the day, saving on transaction fees.

Don't get me wrong, Visa isn't being altruistic in this. The more they can encourage people to move away from debit or cash, the more credit transactions they process and the bigger the interest earning bills.

I have a Visa Platinum card (issued through BofA) so I went looking to verfiy this warranty doubling feature.

I found this, which is an extended warranty program. Pay extra for more warranty. Not what the poster was referring to.

I dug some more and found this, which is a benefit that will replace any item purchased on certain types of Visa cards for any reason, fire, theft, water damage, elephant stepping-on, anything, within the first 90 days of purchase. That's nice, but not the same thing the OP is referring to.

Sorry, but could the OP provide some documentation for this "double warranty" coverage? I'm interested but skeptical. I know that American Express provides that, but I can't find anything that says Visa will do it.