- Can I install nti/payliance-bundle in a Laravel app?
- Composer will happily install the code, but nothing will wire it up. nti/payliance-bundle is a Symfony bundle, so it relies on bundle registration, a DependencyInjection extension, a config tree and service definitions that Laravel does not understand. Laravel has no bundle discovery or config-tree merging, so you get a set of classes and no container bindings, no config file and no facade. Treat it as source material rather than a drop-in dependency.
- Does nti/payliance-bundle support Laravel 10 or Laravel 11?
- Almost certainly not out of the box. The last release dates from 2020, so composer.json likely pins PHP to ^7.2|^8.0 and symfony/* to ^4.4|^5.x, while Laravel 10 ships Symfony 6 and Laravel 11 ships Symfony 7. Composer will refuse to resolve those constraints, and forcing them with --ignore-platform-reqs is not acceptable on a payment path. Check the exact constraints first, then plan to fork rather than require.
- What is the difference between a Symfony bundle and a Laravel package?
- A Symfony bundle ships a Bundle subclass, a DI extension reading a Configuration tree, YAML service definitions and compiler passes, and it is registered in config/bundles.php. A Laravel package ships a service provider with register and boot methods, a publishable config file such as config/payliance.php, and container bindings or facades. The two bootstrapping models are not compatible, so the bundle layer must be replaced by a provider before any of the transport code is usable.
- How do I integrate Payliance payments into Laravel if this is a Symfony bundle?
- The realistic path is to fork the src/ directory into an internal package such as acme/payliance-laravel, strip the bundle scaffolding, and add a PaylianceServiceProvider plus a publishable config/payliance.php with your credentials and environment settings. The alternative is to read the repo purely as a reference for Payliance request and response shapes and rebuild the client natively on Laravel's HTTP client or Saloon. Running a sidecar Symfony service is technically possible but disproportionate for a payment API wrapper.
- Is nti/payliance-bundle maintained and safe for production payments?
- Assume it is not maintained. One star, zero dependents, a single 2020 release and no activity in roughly five years means no CI, no issue triage, no security advisories and no CVE monitoring, plus a bus factor of one. For payment code that is a high-risk profile, so budget for owning the fork outright. Check the licence before you start and confirm whether NTI or Payliance publishes a maintained successor or official SDK.
- Which Payliance endpoints does this bundle cover, such as ACH, card, vault and webhooks?
- That has to be verified by reading the source, because coverage is likely partial. Audit which of ACH debit and credit, card sale and refund, vault/tokenization, batch status, returns and NSF handling, and webhooks are actually implemented. Also determine whether it targets the REST API or the legacy SOAP endpoints, since that changes the migration effort significantly. Expect to fill gaps yourself for anything your product depends on.
- Does the bundle support idempotency keys and webhook signature verification?
- This is the first thing to check, and the answer is often no for packages of this age. Idempotency keys, request signing, retry policy and webhook signature verification are essential for payments, and their absence is a blocker rather than a backlog item. If they are missing, implement them in your fork before anything goes near production. Retry and return-code mapping may also live in the transport layer, so classify each class as transport, DTO or business logic before reuse.
- What PCI and logging risks should I check before using this package?
- Payment code that logs raw request or response bodies can drop PANs and bank account numbers into log files, silently expanding your PCI DSS and SAQ scope. Review every log call, exception message and debug dump in the source, and confirm sensitive values are masked or excluded. Add your own redaction middleware around Laravel's HTTP client and keep credentials in env or a secrets manager. Treat the bundle's defaults as untrusted until proven otherwise.
- How do I test a Payliance integration in Laravel without hitting the live API?
- Wrap the transport behind an interface and mock it with Http::fake or Saloon's MockClient so unit tests never touch the network. Write contract tests from real sandbox request and response samples for success, decline, NSF return and timeout cases. Add explicit tests for idempotency, retries and webhook signature validation. Only a short integration suite should run against Payliance's sandbox with throwaway credentials.
- What are the alternatives to forking nti/payliance-bundle?
- You can build natively against Payliance's current API spec using Laravel's HTTP client or Saloon, which is often cheaper than refactoring if the bundle turns out to be a thin transport wrapper. A community or official Payliance SDK is worth checking for first, and a dedicated Laravel package maintained by someone else would be better still. The fork only wins when the bundle embeds genuinely useful business logic like return-code mapping or tokenization flows. If it is thick, audit it carefully; if it is thin, reimplement it.