Tomato Payments Laravel Package

Product Decisions This Supports

• Multi-gateway portability as a roadmap option, not a rewrite. The package's one real product asset is a single contract over ~11 gateway drivers. Framed correctly, that supports "can we enter a new market with a local processor?" or "can we hedge if our current processor reprices?" as a config-and-driver change instead of a checkout rebuild. The value is optionality — price it as such.
• Build vs. buy on the abstraction layer specifically. Payments itself is integrate-don't-invent, but the layer that hides the gateways is a genuine build/buy call. This package competes against a thin in-house interface over one or two SDKs, not against Stripe. Make that comparison explicit; it is usually the decision that actually gets made.
• Sequencing for billing-adjacent roadmap items. A shared payment/transaction record with migrations shipped means refunds, transaction history in the admin panel, and reconciliation views can be scheduled without a schema design sprint. It also determines whether "add gateway #3" is one sprint or one quarter — a useful estimating input for roadmap commitments.
• Vendor lock-in and exit-cost planning. Every abstraction is a new lock-in candidate. The decision to adopt should name the exit explicitly: what we depend on (our own interface), what we'd replace (the package), and what it costs (one adapter class plus a data backfill key).
• Risk posture for security and legal review. Payment code sits inside PCI scope and credential handling. A one-star, single-maintainer, 2023-dormant dependency is a line item in a security questionnaire, not an engineering footnote. MIT removes the licensing friction; it does nothing for the maintenance signal. Better to surface this in the decision than to have it surface in procurement.
• Discovery cheap enough to just run. As a sandbox spike it answers a product question — "is multi-gateway abstraction worth owning?" — for days of effort rather than a quarter. That is a legitimate spend even if the answer is no.
• A concrete validation gate instead of a vague "supports payments" claim. Judge it against three use cases: (1) a first paid checkout with one gateway, (2) adding a second/regional gateway behind the same interface, (3) refunds and transaction lookup in admin. If it doesn't materially shorten at least one of those, it isn't a product decision yet.

When to Consider This Package

Consider it when:

• You are already inside the TomatoPHP ecosystem — the panels integration, bindings, and conventions are the actual differentiator, and adoption is close to free there. Outside that ecosystem the value narrows to "an adapter we could have written."
• The need is a prototype, demo, or internal spike — sandbox checkout, proof-of-concept for multi-gateway, throwaway validation. Not production money movement.
• You have verified that the 11 wrapped methods cover your near-term requirement including the unglamorous parts — idempotency, webhook signature verification, partial captures, refunds, 3DS/SCA. Surface count is not lifecycle coverage; check the code and a live sandbox before believing it.
• You are prepared to own it — fork it, pin the exact version, treat it as vendored source, and assign a named maintainer. At this signal level, you become the maintainer the moment you depend on it.
• You want it as a reference design for an in-house interface. Reading the driver contract costs almost nothing and is the lowest-risk use available.

Look elsewhere (or write a thin adapter) when:

• The requirement is production payments. No security patches, no fixes for current Laravel/PHP, nobody to escalate to when a gateway changes an endpoint. That is a scheduled replacement, and you should schedule it on day one rather than discover it during a processor migration.
• You need one or two gateways, not eleven. The abstraction premium only pays off with real provider churn; otherwise the processor's first-party SDK is better documented, better supported, and lower risk.
• Lifecycle breadth matters — subscriptions, disputes, partial refunds, tax, payout reconciliation. That is exactly where thin abstractions leak and where you end up forking.
• Someone asks for a support policy, SLA, or security disclosure process. There is no answer to give, and enterprise review will ask.
• The upgrade path is unproven. No release since August 2023 means no evidence of surviving a Laravel major. Estimate that cost before committing; for most teams it exceeds writing the adapter.

Standing rule if adopted: depend on your own PaymentGateway interface, never the package facade directly; keep provider credentials in env only; own the webhook controller and reconciliation columns; and set an explicit re-evaluation trigger at the next Laravel major upgrade.

How to Pitch It (Stakeholders)

To executives: This is a small, MIT-licensed Laravel package that wraps about eleven payment gateways behind one interface, with the database migrations included. It is cheap to trial and not a platform bet. The honest read: it is dormant — last release August 2023, one star, no downstream users — so it is a shortcut for a prototype or an internal tool, not a foundation for revenue-critical checkout. Recommended position: use it to validate multi-gateway abstraction cheaply and to unblock admin transaction/refund surfaces, keep it isolated behind our own interface so it can be swapped in days, and do not take a production dependency on it without a named owner and a stated exit plan. The reason to consider it at all is optionality: if we later need a second or regional gateway, this shows us what that costs before we commit engineering to it.

To engineering: Treat it as vendored source, not a dependency. Wrap it behind our own PaymentGateway interface, resolve drivers per transaction rather than relying on a global default, fake the driver in tests, and write our own webhook endpoint with signature verification, idempotency by provider event ID, and raw-payload logging. Persist our own provider / provider_reference join keys so a future removal is a backfill, not a migration project. Pin the exact version, record the Laravel/PHP versions verified, and watch amount units and currency exponents first — a silent ×100 is the most expensive bug in this category.