Statamic Shopify Laravel Package

Product Decisions This Supports

• Storefront architecture: headless commerce vs. full platform migration. This package is the integration layer that lets a team keep Shopify as the commerce engine (catalog, inventory, checkout, payments, tax) while rendering the storefront with Statamic/Laravel. The decision it informs is "build the storefront on our own stack, buy the commerce backend," rather than replatforming to Shopify themes or migrating to a different commerce platform.
• Roadmap sequencing for content-led commerce. Teams that need merchandising pages, editorial content, landing pages, and localized marketing sites tied to the same product data can scope content features and commerce features on one roadmap instead of two.
• Build vs. buy for the integration itself. The v8.0.0 release shifts the underlying API client to shopify/shopify-app-php, the Shopify-maintained SDK. That reframes the build-vs-buy call: the team is no longer maintaining a bespoke or third-party Shopify API client, only the Statamic-side mapping. This is a meaningful de-risking argument for buying rather than building the connector in-house.
• Upgrade investment decision. A major version bump that swaps the underlying client is a planned engineering workstream, not a routine dependency bump. It becomes a line item competing with feature work and needs a scoping decision (test-and-upgrade now vs. pin to v7.x for the current cycle).
• Vendor and longevity risk. Moving to an official Shopify SDK reduces exposure to abandoned community libraries and aligns the integration with Shopify's own API versioning cadence, which affects long-term support commitments made to stakeholders.

When to Consider This Package

Adopt when:

• Shopify is already, or is about to become, the system of record for payments, fulfillment, and inventory, and the team does not want to rebuild commerce primitives.
• The storefront needs substantial editorial content, custom page composition, or multi-site/multi-locale behavior that is awkward inside a hosted theme.
• The team is already on Statamic/Laravel and values keeping the storefront in a familiar codebase with normal CI, testing, and deployment practices.
• Product, collection, and order data need to be available server-side for custom logic — pricing rules, gated catalogs, B2B-style flows, or bespoke search.
• You are willing to own the mapping layer and can absorb a major-version upgrade when the upstream client changes.

Look elsewhere when:

• The requirement is a straightforward transactional store with standard themes and no content complexity — Shopify native or a hosted theme is cheaper and faster.
• The team has no Laravel/PHP operational depth; the total cost of ownership of a self-hosted storefront plus this integration will exceed expectations.
• You need real-time, high-frequency sync (live pricing at scale, per-second inventory) rather than periodic import of Shopify data into the CMS.
• You are on an older Statamic or PHP version with no appetite to move — v8.0.0's dependency swap should be treated as requiring a supported platform baseline, so verify compatibility before committing.
• The project cannot tolerate a breaking major upgrade in the next 12 months; pinning to v7.x is viable but accrues maintenance debt and delays alignment with the official SDK.

Handling v8.0.0 specifically: this is a breaking release by version number and by nature — any custom code touching the previous API client, cart/checkout calls, or webhook handling may need rework. Budget a spike to audit direct usages, run the storefront regression suite against a Shopify development store, and confirm the new SDK's credential and app-configuration model before scheduling the upgrade.

How to Pitch It (Stakeholders)

For executives: We keep Shopify as the commerce backbone — payments, tax, fulfillment, inventory — and render the storefront on our own Laravel/Statamic stack. That means we buy the expensive, compliance-heavy parts and build only the differentiated front end. The v8.0.0 release moves us onto Shopify's officially maintained PHP SDK, which reduces the risk of the integration rotting when Shopify changes its API and lowers our long-term maintenance burden. It is a breaking release, so it needs a scoped upgrade project rather than an unattended dependency bump.

For engineering: Major version bump; the underlying client is now shopify/shopify-app-php. Treat as breaking: audit every direct call into the previous client, re-verify auth/credential handling against the new SDK's app model, and re-run cart, checkout handoff, webhook, and product/collection sync tests against a Shopify development store before merging. Confirm PHP and Statamic version floors match the new SDK. Recommend doing this in a dedicated branch with a rollback path, and pin v7.x on any project that cannot absorb the change this quarter.

For product: Once upgraded, this unblocks roadmapping content and commerce on a single surface — merchandising pages, localized storefronts, and server-side catalog logic — without asking the team to maintain Shopify API plumbing themselves. Expect one to two sprints of engineering capacity for the upgrade and regression work before new storefront features are scheduled.