Statamic App Api Laravel Package

Product Decisions This Supports

• Customer-facing cancellation truthfulness (trust & support-ticket reduction). v0.2.1 fixes a real customer-visible contradiction: a cancelled subscription whose paid term is still running previously displayed “Beendet am ” alongside “Bezahlt bis ”. The package now emits a single, coherent sentence — “Gekündigt, läuft bis ” while the term runs, “Beendet am ” afterwards — matching the customer portal (Portal\Display::ending()). This is a defect fix that directly reduces “am I cancelled or not?” support contacts and refund/chargeback disputes. Ship it; do not gate behind a feature flag.
• New response contract field: ends_at. Roadmap implication: downstream consumers (account UI, emails, exports, CRM sync, dunning logic) now have an explicit machine-readable end-of-term date instead of parsing labels or inferring from cancellation timestamp. Prioritise wiring ends_at into account pages and lifecycle emails; it is the correct field for “access until” logic and for any proration/win-back targeting.
• B2B/team billing coverage (new capability, default-on). The cancellation confirmation is now also sent to the team’s billing address (statamic-teams billing.email) when it exists and differs from the canceller’s address. Response field copied_to makes this observable and testable. Product decision: this closes a real gap for seat-based/team agreements where the payer is not the person clicking cancel — a finance/accounts-payable expectation. Because the copy is on by default, decide deliberately whether to keep it on per plan/segment; it is a documented CP setting (billing.cancellation_copy_to_team, under Checkout) so it is a policy choice, not an engineering constraint.
• Build vs. buy: delegate, don’t duplicate. The cancel endpoint now calls payments’ own Support\Cancellations::cancel() instead of a forked copy. This is the strategically correct call — cancellation sequencing (state transitions, mail, audit) is upstream’s domain, and every future upstream fix lands for free. Accept the one observable regression: the log entry no longer carries via: app-api. If audit/forensics needs to distinguish API-initiated cancellations, that becomes an explicit, small product requirement rather than accidental metadata.
• Hard dependency gate for roadmap planning. v0.2.1 requires statamic-payments ≥ 1.29.2. Treat this as a coupled upgrade: the label consistency guarantee only holds when the app and the payments package are upgraded together. Do not ship a partial upgrade.

When to Consider This Package

Adopt when all of the following hold:

• You are on Statamic + Laravel with statamic-payments (≥ 1.29.2) as the subscription/billing engine, and this package is the API/bridge layer for billing endpoints.
• You expose cancellation via an API or app surface (POST billing/subscriptions/{subscription}/cancel) and want parity with the customer portal’s wording rather than a second, drifting implementation.
• You sell to teams/organisations via statamic-teams and need the paying party (billing email) notified on cancellation — especially where the canceller and the payer differ.
• You want German-market-consistent lifecycle copy (“Gekündigt, läuft bis …”, “Beendet am …”) without maintaining that string logic yourself.

Look elsewhere, or defer, when:

• You are not on statamic-payments, or you cannot upgrade to ≥ 1.29.2 — v0.2.1’s Changed item is a hard requirement, not a suggestion.
• You need cancellation to remain distinguishable as API-originated in the audit log (via: app-api is gone). Either accept it, or budget a follow-up ticket.
• You require a billing engine with multi-gateway abstraction, tax/ invoicing depth, or dunning beyond what statamic-payments provides — this package is a bridge, not an engine.
• You need non-German lifecycle copy out of the box; the fixed sentences are German-language and would need a localisation layer.
• Your cancellation volume/flow is trivially simple and you would rather call Support\Cancellations::cancel() directly than add a dependency.

How to Pitch It (Stakeholders)

To executives: This is a small, low-risk patch release (v0.2.1) that fixes a customer-visible contradiction in cancellation messaging — customers on a cancelled-but-still-paid plan were shown two conflicting dates. It now says one correct sentence, matching the portal. It also adds a default-on courtesy: when a team’s billing contact is someone other than the person who cancelled, that billing contact gets the cancellation confirmation, which matters for B2B invoicing relationships. No new pricing surface, no schema migration for customers, no change in API answers. One gating condition: the app must upgrade statamic-payments to ≥ 1.29.2 in the same release — schedule them as a single change.

To engineering: Two things to plan around. (1) The cancel endpoint now delegates to payments’ Support\Cancellations::cancel() rather than our copied sequence — same responses and same mail, but the log entry loses via: app-api; flag if anyone queries on it. (2) New contract surfaces to consume: ends_at on the subscription (use it for access-until logic, not the label) and copied_to on the cancellation response (use it for test assertions and support tooling). Verify billing.cancellation_copy_to_team behaviour with three cases: billing email present and different (copy sent), billing email equals canceller (no copy), billing email absent (no copy). Regression-test the label across both states: term still running vs. term elapsed.