Authorize Net Aim Laravel Package

Product Decisions This Supports

• Gateway selection for US card processing. Lets you add Authorize.Net as a payment provider behind a uniform capture / authorize / refund / cancel interface rather than hand-rolling Authorize.Net's AIM request format and error mapping inside your checkout service.
• Build vs. buy for payments plumbing. The decision this supports is not "use this package" but "use Payum's gateway abstraction vs. write our own Authorize.Net client." Payum gives you a request/action model, token lifecycle, and a swap point for another gateway later; this package is the Authorize.Net-specific adapter in that ecosystem.
• Auth-then-capture and merchant-initiated flows. Supports deposit/hold patterns (authorize now, capture on shipment), partial captures, refunds and voids initiated from admin tooling — the classic reasons a merchant picks Authorize.Net over a simple charge API.
• Card-on-file / recurring billing. Pairs with Payum's token and storage model to represent a saved Authorize.Net customer profile, enabling subscription or repeat-charge roadmaps without a separate vaulting vendor.
• Multi-gateway roadmap. If the plan is "Authorize.Net today, Stripe/Braintree/PayPal next quarter," an abstraction layer is a defensible architectural bet that this package plugs into.
• Decisions it does not support well: greenfield checkout UX with hosted payment fields, Apple Pay / Google Pay, 3-D Secure / SCA, or any flow where card data must never touch your servers. AIM is a server-to-server raw-card API; putting it in the request path broadens your PCI scope versus Accept.js or Accept Hosted.

When to Consider This Package

Adopt only under fairly specific conditions:

• You are already a Payum shop. The package is a read-only subtree split of payum/payum; development happens in the monorepo. Do not composer require this artifact directly — require payum/payum and use the Authorize.Net gateway factory. The split's last release was 2016-09-16, so a direct dependency will fight your other constraints.
• You have an existing Authorize.Net account with AIM credentials (API Login ID + Transaction Key) and stored card data or existing recurring profiles you don't want to migrate.
• Your card data is already in a PCI-scoped environment, or your volume is low enough that a SAQ D / SAQ A-EP posture is acceptable.
• You need server-to-server charges — back-office charges, merchant-initiated transactions, admin refunds — where hosted fields don't help.
• You accept the maintenance risk. 2 stars, 0 dependents, and no releases in roughly a decade mean no community support and no expectation of a fast security response. You are pinning and vendoring.

Look elsewhere when:

• Greenfield integration. Use Authorize.Net's Accept.js or Accept Hosted with the official authorizenet/authorizenet SDK to keep PCI scope at SAQ A. This is the single biggest reason to walk away from AIM.
• You want a Laravel-native developer experience. Payum is Symfony-first; there is no first-party Laravel bridge, no Eloquent Storage implementation, and you'd be wiring services, gateway config, and token persistence by hand.
• You aren't otherwise invested in Payum. Pulling in the full abstraction (requests, actions, tokens, storage) to make one API call is a poor trade. A thin client over the official SDK, or omnipay/authorizenet as a lighter abstraction, is a smaller commitment.
• You need active maintenance, 3-D Secure/SCA, Apple Pay/Google Pay, ACH, or Authorize.Net's newer APIs. None of that is served by a 2016-era AIM adapter.

How to Pitch It (Stakeholders)

To executives: This is a free, MIT-licensed adapter that lets our PHP application charge cards through Authorize.Net using Payum, an established payment abstraction library. The strategic upside is optionality — we can add a second processor later without rewriting checkout. The strategic downside is real: this specific artifact is a read-only build byproduct with essentially zero community adoption and no release since 2016, so we would own it. My recommendation is to adopt only if we are already on Payum or are locked into an Authorize.Net account with stored cards; otherwise we should integrate Authorize.Net's hosted/tokenized products, which also materially reduces our PCI compliance burden and audit cost.

To engineering: Treat payum/authorize-net-aim as a component of payum/payum, not a dependency — require the monorepo and instantiate the gateway factory. Expect to supply our own token Storage (Payum ships Doctrine/filesystem implementations, not Eloquent), our own config wiring, and our own error/decline mapping into domain events. The adapter wraps Authorize.Net's legacy AIM server-to-server API, so raw card numbers cross our infrastructure; that is a deliberate compliance decision, not an implementation detail. Budget for pinning the version, vendoring a fork if needed, and using Authorize.Net's sandbox in CI. If the team has no prior Payum investment, the honest estimate is that the abstraction costs more than the integration saves.