NAME

"Business::CreditCard" - Validate/generate credit card checksums/names

SYNOPSIS

    use Business::CreditCard;
 
    print validate("5276 4400 6542 1319");
    print cardtype("5276 4400 6542 1319");
    print generate_last_digit("5276 4400 6542 131");

Business::CreditCard is available at a CPAN site near you.

DESCRIPTION

These subroutines tell you whether a credit card number is self-consistent -- whether the last digit of the number is a valid checksum for the preceding digits.

The validate() subroutine returns 1 if the card number provided passes the checksum test, and 0 otherwise.

The cardtype() subroutine returns a string containing the type of card. The list of possible return values is more comprehensive than it used to be, but additions are still most welcome.

Possible return values are:

  VISA card
  MasterCard
  Discover card
  American Express card
  enRoute
  JCB
  BankCard
  Switch
  Solo
  China Union Pay
  Laser
  Isracard
  Unknown

"Not a credit card" is returned on obviously invalid data values.

Versions before 0.31 may also have returned "Diner's Club/Carte Blanche" (these cards are now recognized as "Discover card").

As of 0.30, cardtype() will accept a partial card masked with "x", "X', ".", "*" or "_". Only the first 2-6 digits and the length are significant; whitespace and dashes are removed. With two digits, Visa, MasterCard, Discover and Amex are recognized (versions before 0.36 needed four digits to recognize all Discover cards). With four digits, almost all cards except some Switch cards are recognized. With six digits (the full "BIN" or "IIN"), all cards are recognized. Six digits are also required for receipt_cardtype().

The generate_last_digit() subroutine computes and returns the last digit of the card given the preceding digits. With a 16-digit card, you provide the first 15 digits; the subroutine returns the sixteenth.

This module does not tell you whether the number is on an actual card, only whether it might conceivably be on a real card. To verify whether a card is real, or whether it's been stolen, or to actually process charges, you need a Merchant account. See Business::OnlinePayment.

These subroutines will also work if you provide the arguments as numbers instead of strings, e.g. "validate(5276440065421319)".

PROCESSING AGREEMENTS

Credit card issuers have recently been forming agreements to process cards on other networks, in which one type of card is processed as another card type.

By default, Business::CreditCard returns the type the card should be treated as in the US. You can change this to return the type the card should be treated as in a different country by setting $Business::CreditCard::Country to your two-letter country code. This is probably what you want to determine if you accept the card, or which merchant agreement it is processed through.

You can also set $Business::CreditCard::Country to a false value such as the empty string to return the "base" card type. This is probably only useful for informational purposes when used along with the default type.

Here are the currently known agreements:

Most Diner's club is now identified as Discover. (This supercedes the earlier identification of some Diner's club cards as MasterCard inside the US and Canada.)
JCB cards in the 3528-3589 range are identified as Discover inside the US and territories.
China Union Pay cards are identified as Discover cards in the US, Mexico and most Caribbean countries.

RECEIPT REQUIREMENTS

Discover requires some cards processed on its network to display "PayPal" on receipts instead of "Discover". The receipt_cardtype() subroutine will return "PayPal card" for these cards only, and otherwise the same output as cardtype().

Use this for receipt display/printing only.

Note: this subroutine is not exported by default like the others. Before 0.36, you needed to call this subroutine fully-qualified, as Business::CreditCard::receipt_cardtype()

In 0.36 and later, you can import it into your namespace:

  use Business::CreditCard qw( :DEFAULT receipt_cardtype );

ORIGINAL AUTHOR

Jon Orwant

The Perl Journal and MIT Media Lab

MAINTAINER

Current maintainer is Ivan Kohler <ivan-business-creditcard@420.am>.

Lee Lawrence <LeeL@aspin.co.uk>, Neale Banks <neale@lowendale.com.au> and Max Becker <Max.Becker@firstgate.com> contributed support for additional card types. Lee also contributed a working test.pl. Alexandr Ciornii <alexchorny@gmail.com> contributed code cleanups. Jason Terry <jterry@bluehost.com> contributed updates for Discover BIN ranges.

COPYRIGHT AND LICENSE

This library is free software; you can redistribute it and/or modify it under the same terms as Perl itself, either Perl version 5.8.8 or, at your option, any later version of Perl 5 you may have available.

BUGS

(paraphrasing Neil Bowers) We export all functions by default. It would be better to let the user decide which functions to import. And validate() is a bit of a generic name.

The question is, after almost 2 decades with this interface (inherited from the original author, who probably never expected it to live half this long), how to change things to behave in a more modern fashion without breaking existing code? "use Business::CreditCard <some_minimum_version>" turns it off? Explicitly ask to turn it off and list that in the SYNOPSIS?

validate() and @EXPORT transition plan

First (done in 0.36):

validate_card() is the new name for validate(). Both work for now.

New-style usage (not recommended for code that needs to support B:CC before 0.36):

  use Business::CreditCard qw( :NEW );

You get validate_card(), cardtype() and receipt_cardtype(). You can also ask for them explicitly / individually:

  use Business::CreditCard qw( validate_card cardtype receipt_cardtype );

Second (we're at now now):

Waiting for 0.36+ to become more prevalent.

Third:

Recommend new-style usage. Maybe asking for a specific minimum version turns it on too?

Fourth: (this is the incompatible part):

Don't export validate() (or anything else [separately?]) by default.

This is the part that will break things and we probably won't do for a long time, until new-style usage is the norm and the tradeoff of breaking old code is worth it to stop or namespace pollution. Maybe do a 1.00 releaes with the current API and 2.00 is when this happens (with a 1.99_01 pre-release)?