Credit Card Industry Group Approves Plan to Track Sales of Guns and Ammo via New Merchant Code

I either missed the answer or the question was mis-understood. I understand the merchant enters eligibility into their system. When I slide the FSA debit card into the reader, how does the system know it is a FSA restricted card and not a regular debit card? Is a query done, or are their certain card number prefixes that identify it as an FSA card and not a regular card?
I thought I answered that.

Every merchant codes their products for XYZ eligibility. Just like they code products for tax exempt or taxable. (If you buy hot fried chicken in a New Hampshire grocery store, it's taxed at the Meals rate; if they pull that same fried chicken because it's reached its shelf life, refrigerate it, and sell it cold, it's no longer taxable.)

Items are coded as WIC-eligible, SNAP-eligible, etc. If the merchant doesn't agree to do that, then they can't accept WIC/SNAP/EBT payments.

When a customer plops down baby food and formula, plus basic staples, plus beer and cigs, the store's system knows which items are approved for purchase under which system. This isn't up to the store: if they don't have items properly coded, the aren't approved to use the different payment systems.

Anyhoo: in that purchase, the customer would run their WIC card first, which would only pay for the WIC-approved items. Then SNAP/EBT, which would pay for the approved food items. And then there would still be a balance left for the beer and smokes, and the customer would have to pay with whatever method they have remaining (cash, debit, credit, check).
 
I thought I answered that.

Every merchant codes their products for XYZ eligibility. Just like they code products for tax exempt or taxable. (If you buy hot fried chicken in a New Hampshire grocery store, it's taxed at the Meals rate; if they pull that same fried chicken because it's reached its shelf life, refrigerate it, and sell it cold, it's no longer taxable.)

Items are coded as WIC-eligible, SNAP-eligible, etc. If the merchant doesn't agree to do that, then they can't accept WIC/SNAP/EBT payments.

When a customer plops down baby food and formula, plus basic staples, plus beer and cigs, the store's system knows which items are approved for purchase under which system. This isn't up to the store: if they don't have items properly coded, the aren't approved to use the different payment systems.

Anyhoo: in that purchase, the customer would run their WIC card first, which would only pay for the WIC-approved items. Then SNAP/EBT, which would pay for the approved food items. And then there would still be a balance left for the beer and smokes, and the customer would have to pay with whatever method they have remaining (cash, debit, credit, check).
He's still looking for the other half: how does the system automatically know that the first card is WIC or SNAP or (in his case) HSA?
 
I thought I answered that.

Every merchant codes their products for XYZ eligibility. Just like they code products for tax exempt or taxable. (If you buy hot fried chicken in a New Hampshire grocery store, it's taxed at the Meals rate; if they pull that same fried chicken because it's reached its shelf life, refrigerate it, and sell it cold, it's no longer taxable.)

Items are coded as WIC-eligible, SNAP-eligible, etc. If the merchant doesn't agree to do that, then they can't accept WIC/SNAP/EBT payments.

When a customer plops down baby food and formula, plus basic staples, plus beer and cigs, the store's system knows which items are approved for purchase under which system. This isn't up to the store: if they don't have items properly coded, the aren't approved to use the different payment systems.

Anyhoo: in that purchase, the customer would run their WIC card first, which would only pay for the WIC-approved items. Then SNAP/EBT, which would pay for the approved food items. And then there would still be a balance left for the beer and smokes, and the customer would have to pay with whatever method they have remaining (cash, debit, credit, check).
Your answer, while mostly complete, does not answer my question "How does CVS determine that a MasterCard is an FSA card and not a regular card without purchase constraints?" There are good answers given to questions other that the one I asked.

Is there a list of BINs (Bank Identification Numbers, first 4 - 6 digits of card) that are FSA cards and if so, is the BIN checked to see if it is an FSA cars online, downloaded for local use by the store's system, or is there a convention about the number that allows CVS to tell without having either a downloaded list or online check?

I know some information is encoded (for example a first digit of 4 means Visa, 5 Mastercard, 3 Amex, etc.) but do not know if the FSA status is encoded in a self contained manner.
 
My question is "How does CVS differentiate between an FSA Master Card and a non-FSA one, as only the former is filtered as to what payments are allowed?"

The fist 6 digits, in almost all cases (in some cases there are 8 digit BINs), of a card is called the BIN. The terminal does a BIN lookup, calls the payment processor for BIN data. The BIN is decoded and the data returned. One of the pieces of data returned is the card "type" which is Flex spending, Healthcase account, personal, commercial ... . Another piece of data returned is credit, debit, reloadable debit, gift card, reloadable goft card ... . Once CVS knows it ia FSA or HSA it uses it own's systems to determine what items are eligible for purchase.
 
Also: BIN lookups are never performed on the terminal or by the merchant. BIN data is updated by the card networks on a regular basis, several times a month, and storing/indexing and searching the data is non-trivial. VISA alone has in excess of 50k BIN values. Each card network has different BIN data. At my job we get the BIN data updates from the card networks, normalize them to a certain extent, and store them in the DB. When we get a request for a lookup we query for the data and then normalize it again so the response data in the same format regardless of the card. The data returned is not always a "full set". We return what we have and in some cases the values of fields are empty/null or not returned. We return the data in 1 of 3 formats, XML, json or an ISO Message.
 
The same way they know it's Visa or MC or Amex or Discover.
Actual, Amputee Marksman covered it nicely. Visa/MC/Amex/Discover can be determined from the first digit. His explanation also covered my a FSA/HSA card will work without product level filtering at stores not specializing in medical stuff.
 
The same way they know it's Visa or MC or Amex or Discover.

WIC and SNAP are referred to as EBT Cards. (Electronic Benefit Cards). They have their own BIN ranges. They are determined in the same way as FSA or HSA card.

VISA has a BIN specification document that is a few hundred pages long. It is updated at least twice a year. MC, AMEX, Discover ... all have BIN specifications also updated. BIN data is updated all the time.

We have a compliance team that does nothing but monitor changes from the card networks and makes sure the systems get updated, tested and rolled into production by the required dates. The PAN on a card is not some random set of numbers. It is like a smart key that holds tons of information on the card and even the card holder.
 
We have a compliance team that does nothing but monitor changes from the card networks and makes sure the systems get updated, tested and rolled into production by the required dates. The PAN on a card is not some random set of numbers. It is like a smart key that holds tons of information on the card and even the card holder.
Plus a cool checksum that will catch any transposition of unlike digits (The Lunh angorithm). Web sites frequently to do this to check credit cards number to make sure they checksum properly before sending the data to the server.
 
WIC and SNAP are referred to as EBT Cards. (Electronic Benefit Cards). They have their own BIN ranges. They are determined in the same way as FSA or HSA card.

VISA has a BIN specification document that is a few hundred pages long. It is updated at least twice a year. MC, AMEX, Discover ... all have BIN specifications also updated. BIN data is updated all the time.

We have a compliance team that does nothing but monitor changes from the card networks and makes sure the systems get updated, tested and rolled into production by the required dates. The PAN on a card is not some random set of numbers. It is like a smart key that holds tons of information on the card and even the card holder.

Have you seen what the new Code and Description is for “gunz”?

Brownells sent out an email to customers their code will not be changing. Not sure how they can state this.

Will this new code/description show up on consumer statement?

Any difference between your Credit Union VISA Debit card vs a Citibank VISA on getting the hammer for sales deemed firearm marked retailers? I’m sure the workers will be rejecting the coded sales sooner than later. It may be the reason to use Bitcoin for purchases until that’s banned to.
 
Also: BIN lookups are never performed on the terminal or by the merchant. BIN data is updated by the card networks on a regular basis, several times a month, and storing/indexing and searching the data is non-trivial. VISA alone has in excess of 50k BIN values. Each card network has different BIN data. At my job we get the BIN data updates from the card networks, normalize them to a certain extent, and store them in the DB. When we get a request for a lookup we query for the data and then normalize it again so the response data in the same format regardless of the card. The data returned is not always a "full set". We return what we have and in some cases the values of fields are empty/null or not returned. We return the data in 1 of 3 formats, XML, json or an ISO Message.

I looked at the visa doc awhile back, Nice how they ID you flew American. Rented at Hertz, stayed at the Bellagio, and shopped at Wally World. It’s not all general categories.
 

The anti-gun legal academics looking to cover the gun control lobby’s tracks…

“When several national banks announced in 2018 that they were backing away from the gun industry in various ways (in response to horrific mass shootings), the gun lobby reinvented Operation Choke Point as a conspiracy among bankers to defund gun dealers. This new, more fanciful narrative about Operation Choke Point has become the stated premise for new antiboycott laws that punish banks if they do not lend to the gun industry, such as Texas SB 19, enacted in 2021.”
 
I was just thinking, not sure if this was already discussed, what happens when a prohibited person orders a T-shirt or hat from a gun manufacturer. Does that person get raided?
 

“An Oklahoma state senator has filed a measure that would prohibit credit card companies from sharing information about gun purchases. Sen. Micheal Bergstrom, R-Adair, filed Senate Bill 814, which is also known as the Oklahoma Second Amendment Financial Privacy Act… Under the measure a credit card company couldn’t disclose a customer’s protected financial information without written consent from the customer.”

Such laws would formally have limited utility, as a lot of information can be gathered without disclosing “protected financial information”. But such laws would “chill” reporting by CC companies concerned about legal repercussions.
 
Back
Top Bottom