Atol Client Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy for payment/fiscal integrations: This package is a thin Laravel wrapper around the upstream atol-client SDK. If ATOL is your fiscal/acquiring provider, adopting the wrapper avoids maintaining bespoke HTTP client code, retry logic, and request/response mapping in-house — a clear "buy/consume" over "build."
• Framework upgrade planning: Release 1.2.1 widens the Guzzle constraint to ^6.2 || ^7.3 and pins atol-client ^1.6.3. Guzzle 7 is the version shipped with modern Laravel (8/9/10), so this release is the compatibility gate that lets the package live on a current Laravel stack. That directly informs whether the integration blocks or unblocks a framework upgrade.
• Dependency and vendor-risk tracking: The package has no code surface of its own in this release — the meaningful change is in its dependency floor/ceiling. Product should treat the upstream atol-client cadence and the wrapper's maintenance activity as the real risk signal, not the wrapper's version number.
• Use-case fit: Relevant only where ATOL is the fiscal/payment counterparty; it enables receipt/fiscalization and related client flows. It is not a general-purpose HTTP or payments abstraction.
• Upgrade sequencing: A patch release that only touches composer constraints is low-risk and can ride the normal dependency-update train — no migration workstream, feature flags, or customer-facing change required.

When to Consider This Package

Consider adopting when:

• You are on Laravel and already (or plan to) integrate with ATOL as your fiscal/payment provider.
• You want a maintained wrapper rather than calling the raw atol-client SDK directly across your codebase.
• You are on, or moving to, Guzzle 7 / current Laravel and need a dependency set that supports it.
• Your integration needs are standard client flows and you value reduced boilerplate over bespoke behavior.

Look elsewhere when:

• ATOL is not your provider — the package is domain-specific and carries no value otherwise.
• You require capabilities the thin wrapper does not expose and would end up bypassing it.
• Your compliance/audit posture requires a vendor-supported or SLA-backed SDK rather than a community wrapper.
• You need long-term support guarantees; a small wrapper's release cadence (and its upstream pin) is a maintenance risk to weigh explicitly.
• You cannot accept the upstream atol-client version floor (^1.6.3) or Guzzle constraints in your dependency graph.

How to Pitch It (Stakeholders)

Executives: This is a small, low-risk dependency-focused patch (1.2.1) to our ATOL integration layer. It does not change product behavior; its value is keeping us current with modern Laravel/Guzzle so the fiscal integration doesn't become the thing that blocks a platform upgrade. Cost of adoption is minimal; the strategic benefit is avoiding custom integration maintenance and staying upgrade-ready.

Engineering: Release 1.2.1 is constraint-only — atol-client ^1.6.3 and guzzle ^6.2 || ^7.3. The Guzzle 7 allowance is the notable item: it unblocks current Laravel versions and removes a common resolver conflict. No API or behavioral changes are implied by the notes, so treat it as a routine bump; verify your lockfile resolves and that your ATOL flows still pass integration tests. Flag the upstream atol-client pin as the dependency to monitor going forward.