- Does nti/authorizenet-bundle work with Laravel?
- No. It is a Symfony bundle built around Symfony's bundle and dependency-injection machinery, which Laravel does not boot. Laravel can consume Symfony components, but it will not register this bundle, load its DI extension, or merge its configuration tree. For Laravel, depend on the Authorize.Net SDK directly and write a small service provider plus a gateway adapter.
- How do I install nti/authorizenet-bundle?
- Install it with Composer in a Symfony application using composer require nti/authorizenet-bundle. Then register the bundle in your Symfony kernel or bundles.php and configure your Authorize.Net credentials through the bundle's configuration tree. There is no Laravel installation path because Laravel does not register Symfony bundles.
- Which Symfony and PHP versions does nti/authorizenet-bundle support?
- The last release was 2023-06-21, which likely predates Symfony 7 and its dependency-injection constraints. Composer conflicts with symfony/framework-bundle or symfony/dependency-injection are plausible on newer Symfony lines. Before committing, prove resolution against your exact PHP and Symfony versions with a composer require in a throwaway branch.
- How do I configure the Authorize.Net API login ID and transaction key?
- The bundle provides a Symfony DependencyInjection extension and configuration tree for the API login ID, transaction key, and sandbox flag. Those values are used to construct the SDK's MerchantAuthenticationType and related request services in the container. In Laravel you would replicate this by binding a configured MerchantAuthenticationType singleton in your own service provider, since the bundle cannot publish config there.
- How do I process a credit card payment with nti/authorizenet-bundle?
- The bundle is thin dependency-injection wiring around the official Authorize.Net PHP SDK. You still build request objects under the net\authorize\api\contract\v1 namespace and inspect string response codes from the SDK. There is no idiomatic Payout::create($amount) style API, so expect the same awkward SDK surface with or without the bundle.
- How do I test Authorize.Net payments in sandbox mode?
- Set the bundle's sandbox flag to true and use sandbox API credentials rather than production keys. Verify that the pinned SDK version is selecting the sandbox endpoint, then exercise successful, declined, and error responses with Authorize.Net test card numbers. Also test void and refund flows, because the bundle does not add behavior beyond SDK wiring.
- Is nti/authorizenet-bundle safe to use in production for payments?
- Treat it with caution. The package shows essentially zero adoption, with 0 stars and 0 dependents, and its last release was 2023-06-21. For code in the payment path, that means no crowd-sourced security review and no public failure history. Pin an exact version and review it line by line, or write the roughly 100 lines of wiring yourself.
- What is the best alternative to nti/authorizenet-bundle for Laravel?
- Use the official authorizenet/authorizenet SDK directly and write a Laravel service provider that binds a configured MerchantAuthenticationType and a thin gateway adapter. That gives you the same integration surface without Symfony bundle coupling. Pair it with Accept Hosted or Accept.js if you want to reduce PCI scope rather than sending card data through your servers.
- How do I reduce PCI scope when integrating Authorize.Net?
- The package choice does not determine PCI scope; the integration pattern does. Server-side Authorize.Net CAPI calls where card data transits your application put you in SAQ D territory. Accept Hosted via iframe keeps card entry off your servers and targets SAQ A, while Accept.js tokenization targets SAQ A-EP. Settle this before choosing any code path.
- Does nti/authorizenet-bundle support recurring billing, Customer Profiles, or webhooks?
- Any ARB, CIM, void, refund, or settlement reporting support comes from the underlying Authorize.Net SDK, not from this bundle. The bundle only wires credentials and request services into Symfony's container, so confirm the pinned SDK version covers each endpoint you need. Test recurring and profile flows in sandbox before relying on them in production.