Skip to content

MyRecipes 1.0 subscription account-binding contract

Issue: #264

Approved policy: #302

Baseline: 2026-08-02

Binding rule

One verified Apple original subscription transaction is bound to one primary MyRecipes Firebase UID at a time. The binding is stored in the trusted purchase_transactions collection under a platform-scoped hash of the original transaction identity. Client-supplied UIDs and local subscription booleans are ignored.

A normal purchase, renewal, or restore may update only the already-bound UID. An attempt to replay the same Apple lineage while signed in to another MyRecipes account returns permission-denied and writes no entitlement to that account. The app explains that the subscription belongs to another account and directs the customer to the original identity or support recovery.

Devices and account switching

  • Device A purchase: Verification binds the original transaction to the signed-in MyRecipes UID.
  • Device B restore: Succeeds when Device B uses the same Apple purchase and the same MyRecipes UID. Device identity is not an entitlement input.
  • Different MyRecipes account on either device: Restore is denied and does not move the binding.
  • Sign-out/account switch: StoreKit and entitlement listeners are rebound by UID; prior entitlement and private Firestore cache are cleared before the new account initializes.

Account deletion

Deleting MyRecipes does not cancel Apple billing. The app warns the customer to manage Apple Subscriptions separately. Live MyRecipes data is deleted under

266, while the purchase ownership record becomes a pseudonymous deletion

tombstone. This prevents the still-active Apple transaction from silently granting a newly created or unrelated MyRecipes account.

Server notifications for a deleted binding do not grant an account. A customer who deleted or lost the bound identity must pass the audited support recovery process before restoring on a replacement MyRecipes account.

Support-controlled recovery

There is no self-service transfer in v1. The support runbook requires target account authentication, corroborated store ownership, a private case and reason, an authorized operator, and a different independent approver. The transfer tool is dry-run by default, atomically rebinds ownership, removes any old live entitlement, and writes a trusted audit record.

The tool never grants access. After an approved transfer, the customer must run Restore Purchases on the target account so the current store transaction is verified again. See Subscription Account Recovery.

Family Sharing

Apple Family Sharing is not supported in MyRecipes 1.0. Legacy receipt verification rejects FAMILY_SHARED ownership, and signed App Store Server Notification and reconciliation paths reject the corresponding JWS ownership type. Store configuration and customer disclosures must not imply Family Sharing support.

Evidence required before closure

Automated tests cover same-UID renewal/restore, second-UID replay denial, deleted-account tombstones, independently approved dry-run/apply transfers, old-account entitlement removal, target verified restore, and Family Sharing rejection. #264 remains open until the Device A/Device B, same-device account switch, deletion with active Apple billing, non-supported Family Sharing, and support recovery scenarios are retained from the designated StoreKit sandbox/TestFlight build. Final deployed canaries remain under #305.