Card type lookup

[quellhorst]

I'd like a feature that lets me do a bin lookup on a tokenized card. This way I could identification prepaid credit cards and gift cards.

[401KC]

+1000

Incorporating this into the API would be really helpful, primarily for reducing fraud. Netflix, for one, is known to filter out prepaid.

The data is definitely available and can be provided, with regular updates, by the processor (ie, First Data). There are several unofficial BIN lookup services but all seem pretty clunky / sketchy. Plus it won't work with tonkenized cards, at least not in a way that's squeaky clean in terms of PCI compliance.

[mahmoudimus]

We already do this internally, we can just expose it as well.

[401KC]

That would be a really useful feature. It's the kind of value-add like the ACH API that differentiates Balanced.

Do you know if your BIN database covers all networks, including Amex. I've previously created my own BIN lookup based on a processor's Global BIN File. But the database did not include Amex.

[bninja]

@quellhorst @401KC here's a preliminary spec for iin (new name for bin):

{
  "card_category": "BUSINESS CARD",
  "card_type": "CREDIT",
  "country_iso3": "USA",
  "country_iso2": "US",
  "country_code": "840",
  "country_name": "UNITED STATES",
}

it would be loaded by your client when you do card.iin.

what do you think?

[quellhorst]

Looks good. I'm curious if you'll expose any other fields.

Example of one BIN lookup I just did:

[mjallday]

I think we could do without country_iso2, country_iso3, and country_code are duplicate information, we should only expose one of them. I agree with @quellhorst that bank contact info would be useful if you need to direct the customer to contact their bank in case of a card declination.

[bninja]

@quellhorst @mjallday how about

{
  "card_category": "BUSINESS CARD",
  "card_type": "CREDIT",
  "country_iso3": "USA",
  "bank_phone_number": "...",
  "bank_url": "...",
  "bank": "..."
}

what other fields do you guys think are legitimate to expose?

[mjallday]

looks good to me.

[quellhorst]

Looks good to me too.

[quellhorst]

Just wanted to make sure. Is "Card_category" the same as "Card Level" in this database?

[mjallday]

@quellhorst I just checked our database, it will return values such as PREPAID, GIFT, PLATINUM, DEBIT, SIGNATURE.

[mahmoudimus]

ping @quellhorst @401KC - what do you guys think of the above pull request. Does it make sense?

[quellhorst]

Yeah, just looked at the diff. Makes sense to me.
👍

[mahmoudimus]

@quellhorst - believe you had some thoughts on this pull request right?

[quellhorst]

In the documentation I'd add the return values for card_category: PREPAID, GIFT, PLATINUM, DEBIT, SIGNATURE

[401KC]

Re: pull request. I don't have a technical background so I can't comment.

Re: the fields. i've got my doubts about "card_category" and actually sent @mjallday an email about it this morning (too detailed for here). here's the summary:

the type of field I think you're pulling from for "card_category" isn't very accurate -- at least not in my experience with BIN Files, even from legitimate sources (eg, a processor). For example, I've seen a gift card show up as just "visa classic" which isn't helpful for prepaid / gift card filtering, a key use case for this data.

Instead, I found two fields very accurate and helpful: 1) Prepaid (Y/N) and 2) Usage (Pin / Signature / Hybrid). I think the discrete set of values helps with accuracy.

I'd push for those, but am not sure what's available to you guys.

[quellhorst]

@401KC I have also seen the same.

Here are some prepaid cards I have, maybe balanced could tell us what values their database has for them:
Amex Prepaid: 374326
Visa Prepaid: 425032

[401KC]

Good idea @quellhorst. Here are some other prepaid BINs (gift cards and reloadables), if Balanced has the time to test them.

374328 - Gift
379014 - Gift
468421 - Gift
601194 - Gift

372741 - Reloadable
401524 - Reloadable
435877 - Reloadable
439347 - Reloadable

[mjallday]

It looks like you should not rely on our current IIN info to determine prepaid cards at this point in time.

  iin   |           brand           | card_type | card_category 
--------+---------------------------+-----------+---------------
 372741 | AMERICAN EXPRESS          | CREDIT    | 
 374326 | AMERICAN EXPRESS          | CREDIT    | 
 374328 | AMERICAN EXPRESS          | DEBIT     | GIFT
 379014 | AMERICAN EXPRESS          | CREDIT    | 
 401524 | VISA                      |           | 
 425032 | VISA                      | CREDIT    | GOLD PREMIUM
 435877 | VISA                      | DEBIT     | PREPAID
 439347 | VISA                      | DEBIT     | PREPAID
 468421 | VISA                      | DEBIT     | PREPAID
 601194 | DINERS CLUB INTERNATIONAL | CREDIT    | CONSUMER CARD

If this is an issue please let us know and we'll investigate what can be done to increase the reliability of our dataset for prepaid card information.

[bninja]

@quellhorst @401KC so it looks like our bin data is not all that reliable. how would you be using it? if its just informational would it be sufficient to expose bin/iin info in the dashboard?

[quellhorst]

@bninja I'd like to be able to access it via api. Would be used to help with manual reviews and automatic flagging. By having you expose what your BIN database has it would make it so I don't have to worry about PCI compliance just so that I could submit the first 6 digits of the card to a 3rd party service like 'MaxMind minFraud'.

I'd rather have some of this data than none of it.

[bninja]

@mjallday @mahmoudimus im fine with exposing iin data provided its noted as informational/advisory as its not reliable. we should also probably expose vai dashboard. anyway lets make the call: merge or reject.

[401KC]

i wouldn't use the feature, with its current (unreliable) dataset. if card type (credit or debit) is wrong 60% of the time (like our examples above), then i think the feature does more harm than good.

however, i think you guys could / should change sources to a BIN file provided by your processor (Chase Paymentech, First Data, or whoever it is). in my experience those datasets are highly accurate for most fields. i'd guess virtually 100% accurate for credit versus debit.

[quellhorst]

Yeah, a more accurate database would be even better. @401KC so you found the best BIN databases for prepaid/gift card identification are available from the CC processor?

[401KC]

@quellhorst absolutely. i've worked with First Data's BIN File and it was perfect for the dozen or so cards I tested. it did have one or two freeform fields with sketchy data but there were plenty of other accurate ones. it makes sense that payment processors have accurate data. they have to charge merchants (via acquiring banks) based on card type, and other characteristics.

[matin]

This issue has been updated to only provide card type (debit, credit, prepaid, etc.) instead of full BIN information.

[jkwade]

Per #419, let's expand the scope of this ticket to include business vs. personal card, in addition to card type.

[lay2000lbs]

Specifically on the debit / credit card identification issue there is another interesting use case.

We do a lot of donation processing for Churches and it's a fairly common request that Churches only want to accept debit cards. That way they never have to worry about someone going into debt giving.

If we could offer specific merchants the ability to only accept debit it would be a nice feature. I think Faith Street + Simple Donation would probably like this feature as well.

[remear]

API 1.1 provides the type, brand, bank_name, and category attributes on Card resources.

{
    "cards": [
        {
            "address": {
                "city": null, 
                "country_code": null, 
                "line1": null, 
                "line2": null, 
                "postal_code": null, 
                "state": null
            }, 
            "avs_postal_match": null, 
            "avs_result": null, 
            "avs_street_match": null, 
            "bank_name": "BANK OF HAWAII", 
            "brand": "MasterCard", 
            "can_credit": false, 
            "can_debit": true, 
            "category": "other", 
            "created_at": "2014-09-29T22:44:18.742987Z", 
            "cvv": "xxx", 
            "cvv_match": "yes", 
            "cvv_result": "Match", 
            "expiration_month": 12, 
            "expiration_year": 2020, 
            "fingerprint": "fc4ccd5de54f42a5e75f76fbfde60948440c7a382ee7d21b2bc509ab9cfed788", 
            "href": "/cards/CC19fTfHe7Qew0ZondF3tpoF", 
            "id": "CC19fTfHe7Qew0ZondF3tpoF", 
            "is_verified": true, 
            "links": {
                "customer": null
            }, 
            "meta": {}, 
            "name": null, 
            "number": "xxxxxxxxxxxx5100", 
            "type": "credit", 
            "updated_at": "2014-09-29T22:44:18.742989Z"
        }
    ], 
    "links": {
        "cards.card_holds": "/cards/{cards.id}/card_holds", 
        "cards.customer": "/customers/{cards.customer}", 
        "cards.debits": "/cards/{cards.id}/debits", 
        "cards.disputes": "/cards/{cards.id}/disputes"
    }
}