Transactor Laravel Package

Product Decisions This Supports

• Gateway expansion (build vs. buy): The addition of Authorize.Net Card and ACH transactors means adding Authorize.Net as a payment option — including bank-debit/ACH for invoicing and recurring use cases — becomes configuration work rather than a bespoke integration project. Directly inform the "which processors do we support at launch" roadmap decision.
• Card-present roadmap: Improved swiped-card data decoding plus the new EncryptedSwipedCardAccount open up POS/terminal/mobile-reader scenarios. Use this to decide whether card-present is in scope before committing to a payment abstraction.
• Tokenization is groundwork, not a feature: The release adds "basic plumbing" for tokenizing sensitive account data. Treat this as a signal to plan a vaulting/tokenization epic — do not roadmap or market it as a delivered security capability.
• Multi-framework estate consolidation: Symfony 2.3+/3.0+ support means the same payment layer can serve both a Laravel application and Symfony services, reducing duplicate gateway integrations across teams.
• Migration budgeting: TransactorInterface::createCredentials is a mandatory BC break for every Transactor. If we have custom transactors, this is a tracked engineering cost against the upgrade.

When to Consider This Package

Strong fit when:

• You need multiple gateways behind one interface and want to swap processors without rewriting checkout.
• Authorize.Net (card or ACH) is on the near-term roadmap.
• Card-present/swiped input is likely and you want decoding and encryption handled by the library rather than in-house.
• You run Laravel alongside Symfony services and want one payment layer for both.
• You have no custom TransactorInterface implementations, or only a small number you can migrate quickly.

Look elsewhere when:

• You need a production-ready tokenization/vault today — only plumbing exists; you would be building the vault or buying the gateway's.
• Your runtime is Symfony 4/5+ or a modern PHP version. "Symfony 2.3+/3.0+" describes an older compatibility band; verify actual support before assuming fit with a current stack.
• You require vendor SLAs, first-party support, or gateways outside the supported set.
• PCI scope reduction is a hard requirement and you cannot own encryption/key management for swiped data.
• You need a Laravel-native package with explicit Laravel-version guarantees and a predictable release cadence.

How to Pitch It (Stakeholders)

For executives: This release lets us add Authorize.Net — both card and bank-debit payments — without funding a custom integration, and it improves support for card-present payments. Both are revenue-relevant additions at low incremental effort. Two caveats worth stating plainly: the tokenization work in this release is foundation, not a finished secure-vault capability, so it should not be counted as delivered; and there is a one-time engineering cost to update our own payment code because the transactor interface changed.

For engineering: Version 1.2.0 adds Symfony 2.3+/3.0+ support, an Authorize.Net card and ACH transactor, improved swiped-card decoding, and a new EncryptedSwipedCardAccount. There are two breaking changes to plan for: TransactorInterface now requires a createCredentials method on all transactors, and SwipedCardAccount no longer populates account information when track data is set — a Track Decoder must be used instead. Estimate the migration as small if we ship no custom transactors, and material if we do.