- How do I install rap2hpoutre/laravel-credit-card-validator in a Laravel app?
- Install it with Composer using composer require rap2hpoutre/laravel-credit-card-validator. The package ships a service provider that is auto-discovered on Laravel 5.5 and later, so the credit_card rule is registered with the validator without any manual wiring. There is no config file to publish and no migrations to run. If the command fails on your stack, check the version constraints in the package's composer.json before trying any workaround flags.
- Which Laravel and PHP versions does laravel-credit-card-validator support?
- The package was last released in October 2020, so its composer.json constrains illuminate/support and PHP to versions from the Laravel 6 to 8 era. It works cleanly on those versions, but Composer resolution will likely block installation on Laravel 9, 10, or 11. Verify it against your exact PHP and Laravel matrix in CI before adopting it, and do not assume forward compatibility just because the rule itself is simple.
- How do I use the credit_card rule in a Laravel Form Request?
- Add the rule as a string in your Form Request's rules() method, for example 'card_number' => ['required', 'credit_card'], or inline via Validator::make. It composes with standard modifiers like bail, required, nullable, and sometimes, so you can slot it into an existing rule chain without restructuring anything. Because it is just a rule string, your call sites stay independent of the package's class names and the implementation can be swapped later.
- Can it detect the card brand, like Visa, Mastercard, or Amex, as well as validate the number?
- Yes. The rule runs a Luhn checksum on the number and matches the IIN prefix to identify the card brand, including Visa, Mastercard, Amex, and others. The validation result is pass or fail, so check the README for your installed version to see whether the detected type is exposed to application code or only used internally for the check. If you need the brand to route to a PSP-specific flow, confirm that behaviour before designing around it.
- Does it validate the expiration date and CVV as well as the card number?
- The core credit_card rule is about the number: Luhn validity plus brand detection. The package overview also advertises rules for expiration date and CVV, so check the README and rule list for the exact rule names available in your installed version. Either way, treat these as format and sanity checks only, since real expiry and CVV verification happens at the payment gateway when the authorization is attempted.
- Is this package a PCI DSS compliance control or a fraud prevention tool?
- No. It is input hygiene at the request boundary: it stops obvious typos and malformed numbers from burning authorization attempts against your PSP. It does not reduce PCI DSS scope, does not tokenize card data, and does not detect fraud. Do not let stakeholders treat a passing credit_card rule as evidence that card data is safe or that the field is compliant.
- What should I do if composer require fails on Laravel 10 or Laravel 11?
- Do not reach for --ignore-platform-reqs or constraint overrides just to install a 2020-era validation helper, especially in a payment-adjacent path, because pinning around a stale dependency graph costs more than it saves. The pragmatic option is to vendor the logic: a Luhn check plus an IIN prefix map is roughly fifty lines and can live in your own Rule class behind the same credit_card rule string. That keeps your Form Requests unchanged and removes the abandoned dependency. Reimplementing also lets you own the BIN table and update it on your own schedule.
- Does the package log, echo, or store the raw card number anywhere?
- Nothing in the described architecture writes to storage, queues, or logs, because it is a pure validator with no models or persistence. That said, your own application is the real risk: make sure failed validation does not dump the request payload, including the PAN, into exception handlers, log channels, or error tracking. Review the package source and its test suite once before adoption so you know exactly what it touches on failure.
- Is the package still maintained, and what are the alternatives?
- The last release was October 2020, it has around 21 stars, and it is maintained by a single author, so expect no PHP 8.3 or Laravel 11 support and no response to issues. Alternatives are a native Laravel Rule object or closure rule wrapping a Luhn implementation, which is the idiomatic choice on Laravel 9 and above. There are also dedicated card-validation libraries, but they add a transitive dependency for something you can write in an afternoon. Many teams simply keep the credit_card rule string and swap the implementation behind it.
- How do I test the credit_card rule without hitting a payment gateway?
- Card number validation is deterministic and offline, so you can unit test it with known-good and known-bad numbers from each brand, plus edge cases like spaces, hyphens, and empty strings. Assert that valid numbers from Visa, Mastercard, and Amex pass, that a single transposed digit fails the Luhn check, and that a number with a valid checksum but an unknown prefix is rejected. If you wrap the rule in your own class, test the rule string through Validator::make so the test stays valid after any swap of the underlying implementation.