Implement and verify subscription billing

Why use this

1. A product team launching subscriptions needs payment state and application access to agree across several components. A successful-looking checkout can conceal that cancelled, failed or duplicate events leave users with the wrong entitlements.

2. This job could make the intended billing/access behavior reviewable before implementation and deployment. Separating test-mode evidence from production operation helps the owner decide whether a proposed change is ready for authorized verification.

Why an agent / simpler alternative

Useful judgment

Map subscription states to access rules, identify cross-system edge cases and connect implementation review with explicit acceptance criteria.

Simpler alternative

Use a supported hosted subscription setup when its access model fits without custom logic.

Unsuitable when

The task requires handling live payment secrets, unapproved charges or production changes without user review.

Proposed inputs

1. Name

   Subscription brief

   Owner

   Product owner

   Minimum scope

   Plan definitions, access rules and cancellation behavior

   Quality check

   Confirm recurring commitment and entitlement boundaries

2. Name

   Application architecture

   Owner

   Authorized maintainer

   Minimum scope

   Relevant routes, identity/data model and test environment description

   Quality check

   Exclude credentials and identify authoritative billing state

Access and setup — proposed or unknown

Proposed minimum

1. Begin with a state-transition table and proposed test plan; no account configuration, code execution, deployment or charge.

Compatibility unknowns

1. Current provider APIs, webhook behavior, test-mode support and exact runtime compatibility are unknown.

External actions requiring approval

1. Credential creation, billing configuration, deployment and transactions require applicable approval; user review/merge remains explicit.

Expected deliverable and review checks

Proposed artifact

Implementation specification with proposed PR scope, access-state matrix and unexecuted test-charge checklist.

Critical checks

1. Distinguish test/live modes; cover failed, cancelled and duplicated events; verify access is tied to authoritative state.

Missing output evidence

This overlay adds no new output inspection, execution or validation; consult the referenced canonical source outcome limits.

Failure signals and proposed responses

1. Signal

   A duplicate event creates duplicate entitlement

   Why it matters

   Retries can alter access incorrectly

   Proposed response

   Specify idempotent handling and a test case before implementation.

2. Signal

   Cancellation changes billing but not access

   Why it matters

   Systems disagree about the user's entitlement

   Proposed response

   Define the intended effective date and reconcile both states.

Effort and cost — unknown

Setup work

1. Define state ownership and safe test boundaries.

Ongoing review

1. Owner reviews code and qualified staff inspect authorized test evidence.

Unknowns

1. Provider configuration, regulatory obligations, integration effort and charges are unknown.

First check — proposed, unexecuted

Status

proposed_unexecuted

Synthetic fixture

Invent subscription events for trial, success, failure, duplicate notification and cancellation; map expected access states on paper.

Acceptance checks

1. Keep test data separate; expose unspecified states; propose no live charge or automatic merge.

Stop conditions

1. Stop before credentials, transactions or production changes without required authorization.

Limits

1. A proposed billing design cannot establish payment compliance, production reliability or successful subscription collection.