- Is paymentsuite/authorizenet-bundle compatible with Laravel?
- No. It is a Symfony bundle from the PaymentSuite ecosystem registered through the Symfony kernel; it has no Laravel service provider, facade, config publishing, or illuminate/* dependencies. Dropping it into a Laravel app would at best be inert and could cause container or bootstrap conflicts.
- Which Laravel versions does this Authorize.Net bundle support?
- None. There are no Laravel version constraints because the package does not target Laravel. On Laravel 10 or 11 you should expect Composer resolution conflicts and code that fails on modern PHP.
- What PHP and Symfony versions does this package require?
- It is a 2014-era Symfony 2.x bundle that will typically pin symfony/symfony or framework-bundle to the 2.x line and PHP to around 5.3 or 5.4. It is not compatible with Symfony 6/7 or PHP 8.x without a rewrite.
- How do I install paymentsuite/authorizenet-bundle?
- Installation is only realistic inside a legacy Symfony 2.x application via Composer. On a modern Laravel or Symfony stack, Composer resolution will likely fail because of old PHP and Symfony constraints. Do not attempt to force-install it into a current Laravel app.
- Is this package still maintained?
- No. The last release was 2014-04-19, and there is no CI, no test suite, no recent issue activity, and zero dependents. Treat it as abandoned and unverified in production.
- Is it safe to use for production payments and PCI compliance?
- High risk. The bundle appears to follow the legacy AIM pattern where card data is posted from your server to Authorize.Net, with no visible tokenization or CIM vaulting. Unmaintained code handling PAN in-process is a serious PCI-DSS and breach exposure; modern integrations should use Accept.js or Accept Hosted so card data never touches your infrastructure.
- Does it support Authorize.Net Accept.js or Accept Hosted tokenization?
- There is no visible support for Accept.js or Accept Hosted in this legacy bundle. Authorize.Net has retired older SIM/DPM paths and moved toward hosted fields and redirect flows, so the request/response contract is unverified and likely outdated. You would need to build a current tokenized integration instead.
- Can I use it for recurring billing, ARB, or CIM vaulting?
- Probably not. This is a thin payment-method adapter intended for one-time card-not-present charges inside PaymentSuite's order and transaction orchestration. It does not advertise recurring billing, ARB, or vaulted CIM support, so you should not rely on it for subscriptions or stored credentials.
- What should Laravel developers use instead for Authorize.Net?
- Use a maintained Authorize.Net SDK or a small, well-tested in-house client built against the current Transaction API, with Accept.js for client-side tokenization and Accept Hosted for redirect flows. For Laravel, wrap that client in your own service provider and configuration rather than pulling in an abandoned Symfony bundle. This gives you control over idempotency, AVS/CVV handling, and PCI scope.
- Can I use this bundle as a reference implementation?
- Yes, but read it rather than require it. Its value is as a worked example of how PaymentSuite mapped a payment method, translated response codes, and abstracted the gateway call. Reimplement those ideas against the current Authorize.Net API instead of adding the dependency.