---
id: FAS-MBR-MEM-03
feature: FEAT-MBR-MEM-03
product_area: membership
module: memberships
revision: 1
status: proposed
product_intent: proposed
source_sha:
  services-membership: 5994c270e8a37a30f848e99ba5b5ee6b87c08893
  react-console: baf6dae382d6f41dce976c7f848667ccc37e076f
capabilities:
  - CAP-MBR-MEM-009
  - CAP-MBR-MEM-010
scenarios:
  - id: FAS-MBR-MEM-03-01
    title: Make purchased rights visible only after fulfilment
    kind: behaviour
    exercises:
      - CAP-MBR-MEM-009
    relies_on:
      - ATS-MBR-MEM-009-01
      - ATS-MBR-MEM-009-10
      - ATS-MBR-MEM-009-12
      - ATS-MBR-MEM-010-07
    preconditions: A new person has a package with an optional dues-bearing chapter.
    steps:
      - do: >-
          Advise checkout, place it, inspect pending coverage, fulfil it and
          replay the authorization.
        expect: >-
          Preparation changes nothing; placement reserves coverage; fulfilment
          produces one numbered holding and replay returns the same records.
        provenance: test
        source: 'services-membership:tests/e2e/commerce-purchase.e2e.spec.ts'
    expected: >-
      Preparation changes nothing; placement reserves coverage; fulfilment
      produces one numbered holding and replay returns the same records.
    negative: false
    data_needs: >-
      An isolated workspace, dated member fixtures, chapter and package
      configuration, and recording partner ports where the case requires them.
    bound_to:
      - TST-MBR-MEM-241
    provenance: test
    source:
      - 'services-membership:tests/e2e/commerce-purchase.e2e.spec.ts'
      - >-
        services-membership:modules/commerce-participant/tests/unit/purchase-plan.spec.ts#carries
        no amount anywhere
      - >-
        services-membership:modules/commerce-participant/tests/integration/participant.integration.spec.ts#claims
        under the capability role: a pending, unnumbered membership with its
        pending term and claim
      - >-
        services-membership:modules/commerce-participant/tests/integration/participant.integration.spec.ts#fulfils:
        committed with its authorization, numbered, its chapter written with the
        dues product, enrolled
      - >-
        services-membership:modules/commerce-participant/tests/integration/participant.integration.spec.ts#releases
        a voided order: the pending term and the membership the claim created
        are deleted
    binding_evidence:
      - suite: TST-MBR-MEM-241
        source: 'services-membership:tests/e2e/commerce-purchase.e2e.spec.ts'
  - id: FAS-MBR-MEM-03-02
    title: Release reserved dates before a replacement purchase
    kind: interaction
    exercises:
      - CAP-MBR-MEM-009
      - CAP-MBR-MEM-010
    relies_on:
      - ATS-MBR-MEM-009-10
      - ATS-MBR-MEM-010-07
    preconditions: A first purchase or renewal owns pending coverage.
    steps:
      - do: >-
          Void the unpaid order, then prepare and place a replacement purchase
          for the same dates.
        expect: >-
          The released claim no longer blocks replacement; an existing renewed
          holding survives release while an empty first-purchase holding does
          not.
        provenance: proposed
        source: &ref_0
          - >-
            services-membership:modules/commerce-participant/tests/integration/participant.integration.spec.ts#claims
            under the capability role: a pending, unnumbered membership with its
            pending term and claim
          - >-
            services-membership:modules/commerce-participant/tests/integration/participant.integration.spec.ts#releases
            a voided order: the pending term and the membership the claim
            created are deleted
    expected: >-
      The released claim no longer blocks replacement; an existing renewed
      holding survives release while an empty first-purchase holding does not.
    negative: false
    data_needs: >-
      An isolated workspace, dated member fixtures, chapter and package
      configuration, and recording partner ports where the case requires them.
    bound_to: []
    provenance: proposed
    source: *ref_0
  - id: FAS-MBR-MEM-03-03
    title: Close purchased coverage while fencing competing renewal
    kind: lifecycle
    exercises:
      - CAP-MBR-MEM-009
      - CAP-MBR-MEM-010
    relies_on:
      - ATS-MBR-MEM-009-05
      - ATS-MBR-MEM-010-05
      - ATS-MBR-MEM-010-06
      - ATS-MBR-MEM-010-09
    preconditions: A package purchase is fulfilled with a chapter affiliation.
    steps:
      - do: >-
          Prepare cancellation, claim its fence, attempt a competing renewal,
          complete cancellation and replay its obligation.
        expect: >-
          The competing purchase is refused while fenced; cancellation closes
          the term and chapter and clears the fence; replay returns the same
          records.
        provenance: test
        source: 'services-membership:tests/e2e/commerce-cancellation.e2e.spec.ts'
    expected: >-
      The competing purchase is refused while fenced; cancellation closes the
      term and chapter and clears the fence; replay returns the same records.
    negative: false
    data_needs: >-
      An isolated workspace, dated member fixtures, chapter and package
      configuration, and recording partner ports where the case requires them.
    bound_to:
      - TST-MBR-MEM-240
    provenance: test
    source:
      - 'services-membership:tests/e2e/commerce-cancellation.e2e.spec.ts'
      - >-
        services-membership:modules/commerce-participant/tests/unit/eligibility.spec.ts#refuses
        a suspended membership
      - >-
        services-membership:tests/e2e/commerce-cancellation.e2e.spec.ts#fences
        the membership in TX-K, refusing a competing purchase meanwhile
      - >-
        services-membership:tests/e2e/commerce-cancellation.e2e.spec.ts#answers
        a redelivered cancel obligation with the same records
      - >-
        services-membership:tests/e2e/commerce-cancellation.e2e.spec.ts#terminates
        the term the day before the effective date, ends its chapter, clears the
        fence
    binding_evidence:
      - suite: TST-MBR-MEM-240
        source: 'services-membership:tests/e2e/commerce-cancellation.e2e.spec.ts'
  - id: FAS-MBR-MEM-03-04
    title: Distinguish the member’s cancellation from staff authority
    kind: permission
    exercises:
      - CAP-MBR-MEM-009
      - CAP-MBR-MEM-010
    relies_on:
      - ATS-MBR-MEM-009-12
      - ATS-MBR-MEM-010-04
    preconditions: A member has both a pending purchase and started purchased coverage.
    steps:
      - do: >-
          Ask to cancel each as the member and as staff, then inspect the
          preparation answers without placing a cancellation.
        expect: >-
          The pending cancellation can proceed for the member; started coverage
          requires approval for the member while staff preparation can proceed.
        provenance: proposed
        source: &ref_1
          - >-
            services-membership:modules/commerce-participant/tests/integration/participant.integration.spec.ts#fulfils:
            committed with its authorization, numbered, its chapter written with
            the dues product, enrolled
          - >-
            services-membership:tests/acceptance/commerce/MBR-ACC-0335.acceptance.ts#MBR-ACC-0335
    expected: >-
      The pending cancellation can proceed for the member; started coverage
      requires approval for the member while staff preparation can proceed.
    negative: true
    data_needs: >-
      An isolated workspace, dated member fixtures, chapter and package
      configuration, and recording partner ports where the case requires them.
    bound_to: []
    provenance: proposed
    source: *ref_1
  - id: FAS-MBR-MEM-03-05
    title: Keep paid coverage unique under delivery replay
    kind: regression
    exercises:
      - CAP-MBR-MEM-009
      - CAP-MBR-MEM-010
    relies_on:
      - ATS-MBR-MEM-009-12
      - ATS-MBR-MEM-010-06
    preconditions: A fulfilled purchase can subsequently be cancelled.
    steps:
      - do: >-
          Replay fulfilment after its first acknowledgement, complete
          cancellation, and replay cancellation after its first acknowledgement.
        expect: >-
          Each replay returns the original records without adding another
          period, closure or business event.
        provenance: proposed
        source: &ref_2
          - >-
            services-membership:modules/commerce-participant/tests/integration/participant.integration.spec.ts#fulfils:
            committed with its authorization, numbered, its chapter written with
            the dues product, enrolled
          - >-
            services-membership:tests/e2e/commerce-cancellation.e2e.spec.ts#answers
            a redelivered cancel obligation with the same records
    expected: >-
      Each replay returns the original records without adding another period,
      closure or business event.
    negative: false
    data_needs: >-
      An isolated workspace, dated member fixtures, chapter and package
      configuration, and recording partner ports where the case requires them.
    bound_to: []
    provenance: proposed
    source: *ref_2
evidence:
  - >-
    rhythm-v2-docs:specs/membership/memberships/planning/features/FEAT-MBR-MEM-03-selling-membership-through-commerce.md
  - >-
    rhythm-v2-docs:specs/membership/memberships/design/tests/: detailed
    capability scenarios and interaction cases.
  - 'services-membership:tests/e2e/commerce-purchase.e2e.spec.ts'
  - 'services-membership:tests/e2e/commerce-cancellation.e2e.spec.ts'
---

# Membership Purchases and Payment Consequences: Feature Acceptance Suite

## What the Feature Must Do as a Whole

This suite tests the purchase lifecycle from preparation and reservation to fulfilment, release and cancellation. Composite cases expose the effect of an outstanding reservation or cancellation on a competing purchase.

## Interactions Between Capabilities

The composite cases test the effect of a change in one capability on the records and answers of another. Detailed reliance links identify the supporting capability scenarios; an executable binding requires assertions for the complete feature case. Cases without such a binding remain proposed.

## Regression Record

| Revision | Change | Scenario | Why |
|---|---|---|---|
| 1 | initial | all | Establish cumulative feature coverage from the pinned specification and executable evidence. |