- How do I install jlorente/laravel-credit-cards in a Laravel app?
- Run composer require jlorente/laravel-credit-cards in your project root. The package supports Laravel 5.6 and newer and registers its service provider and facade through package auto-discovery, so no manual provider entry is needed. There are no migrations, queue workers, or scheduled tasks involved, and the config surface is small, so a basic integration is just the Composer require plus one or two validation rule usages in your form requests.
- Which PHP and Laravel versions does jlorente/laravel-credit-cards support?
- The package targets Laravel 5.6 and above. The exact PHP floor is governed by the underlying php-credit-cards dependency, and version 1.0.3 bumped that dependency to its latest release, so check the resolved version's composer.json for the current PHP constraint. Confirm the transitive tree resolves cleanly against your locked PHP and Laravel versions before merging.
- How do I validate a credit card number with the Luhn algorithm in a Laravel form request?
- Use the package's validation rules inside your FormRequest rules method instead of hand-rolling a Luhn check. The package wraps the php-credit-cards library, so you get Luhn checksum validation, card brand detection, and CVV and expiry length rules through a single API. Adopt it at one centralized validation point rather than scattering card rules across controllers.
- Does jlorente/laravel-credit-cards detect the card brand or type?
- Yes. Brand detection runs against the card-type and BIN tables bundled in the upstream php-credit-cards library, so it identifies brands such as Visa, Mastercard, and Amex from the number prefix. Because those tables ship statically, support for a newly issued card range only arrives when the upstream dependency is updated.
- Does this package make external API calls for BIN lookups?
- By design the validation is local: Luhn checksum, brand detection, and length rules run against bundled data with no outbound HTTP requests. That matters for both latency and compliance, since shipping card numbers to a third-party BIN service changes your risk profile substantially. Verify this against the resolved dependency version before relying on it, because a dependency bump could in principle introduce a remote lookup.
- Will using this package put my application in PCI DSS scope?
- The package stores nothing, transmits nothing, and holds no state, which keeps it out of PCI DSS scope as long as you never log or persist the card number. Your application can still fall into scope through what you do with the PAN before and after validation, so keep the rules in shared validation code and make sure PANs never reach logs, exception traces, or the database.
- Can I test the validation rules with test card numbers like 4111111111111111?
- Yes. Standard test PANs such as 4111111111111111 work for asserting valid paths, and you should pair them with known-invalid numbers and brand-boundary PANs in a fixture file, for example tests/Fixtures/cards.php. Because card-brand tables can shift between upstream releases, keep that fixture set as a permanent contract test so a dependency bump that changes a validation outcome fails CI rather than production checkout.
- What changed in jlorente/laravel-credit-cards 1.0.3 and is it safe to upgrade?
- Version 1.0.3 is a patch-level release that bumps the bundled php-credit-cards dependency to its latest version, with no API changes or deprecations called out. The blast radius is confined to validation outcomes rather than call signatures, because in this package the upstream library is effectively the product. Read the upstream changelog between your previously resolved version and the new one for changes to brand tables, BIN ranges, CVV lengths, or the PHP version floor, then run your contract tests before merging.
- What are the alternatives to jlorente/laravel-credit-cards?
- You can use the underlying php-credit-cards library directly, another Composer validator such as inacho/php-credit-card-validator, or a hand-written Luhn check plus regex brand detection. The bigger alternative in most stacks is to skip server-side card validation entirely and let a payment gateway's tokenization flow handle card data so the PAN never reaches your server. This package fits best when you want lightweight, local validation inside Laravel form requests.
- How actively is jlorente/laravel-credit-cards maintained, and what happens when card brand data goes stale?
- The package is a thin integration layer, so its maintenance cadence largely tracks the upstream php-credit-cards project. The standing risk is data aging: card-brand and BIN tables are bundled, and a validator that rejects a legitimate new card range produces a hard checkout failure for the affected users. Before adopting or upgrading, check recent commits, any open CVE, and deprecation notices upstream, and keep contract tests that catch validation drift.