Weave Code
Weaver
Helps Laravel developers discover, compare, and choose open-source packages. See popularity, security, maintainers, and scores at a glance to make better decisions.
Feedback
Share your thoughts, report bugs, or suggest improvements.
Subject
Message
Authorizenet Bundle

Authorizenet Bundle Laravel Package

paymentsuite/authorizenet-bundle

PaymentSuite integration for Authorize.Net that lets PHP applications route card payments through Authorize.Net’s gateway using configurable API credentials and PaymentSuite’s standard payment workflow, simplifying gateway setup within existing PaymentSuite-based projects.

View on GitHub
Deep Wiki
Context7

AuthorizeNetBundle brings the Authorize.Net payment gateway into the PaymentSuite ecosystem, giving Symfony applications a ready-made payment method with minimal setup. It wraps gateway communication behind PaymentSuite's payment processor interfaces so you can accept card payments without wiring the API by hand.

  • Plugs into PaymentSuite via the standard PaymentMethod interface
  • Switch between sandbox and production credentials through configuration
  • Supports authorize-and-capture and authorize-only flows
  • Service-based architecture registered through the DI container
  • Installs as a conventional Symfony bundle with its own configuration tree
Frequently asked questions about Authorizenet Bundle
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.
Weaver

How can I help you explore Laravel packages today?

Conversation history is not saved when not logged in.
Prompt
Add packages to context
No packages found.
elsayed85/laravel-api-exceptions
ouhssini/laravel-demo-mode
daworks/ncloud-outbound-mailer-driver
gp247/cms
ignibyte/aic-gates
nexa-merchant/blog
novasa/laravel-language-center
opencage/geocode
adolfoholzer/parameters
livenetworks/ln-starter
shitoudev/permissionmanager
johannesclimacus/laravel-tui
hocvt/seotools
vitalybaev/sypexgeo
amphibee/themosis-ignition
gito-me/fast-excel
frankyso/laravel-ipaymu
geolize-studio/laravel-chile
boomerangui/chat
cgv/localized-resource