@chipmobilesdk/rn-payment 0.2.1 → 0.3.0

package/CHANGELOG.md

@@ -7,6 +7,23 @@ product keys, error codes, event names, state values, message keys, and the
 public API shape are this package's contract: renaming any of them is a breaking
 change.
 
+## [0.3.0] — 2026-10-13
+
+Documentation release: the README and the agent skill now match the code `0.2.1` shipped.
+**No code, API, storage or behaviour change** — upgrading from `0.2.1` changes nothing at
+runtime. Released as its own version so the skill a consuming app syncs (`packageVersion`)
+always matches the package it came from.
+
+### Changed
+
+- README `### Migrating 0.1.0 to 0.2.0`: no longer claims `0.1.0` persisted pending records.
+  On a device nothing persisted before `0.2.1`; the section now says to use `0.2.1` or
+  later and what a device first running it does (empty record, `unknown` until the first
+  sync, never a false `not_entitled`).
+- README intro: "Android only for now" instead of a version-pinned phrase.
+- Skill: "Require `0.2.1` or later" under the upgrade notes, with the reason; the public
+  API heading names `v0.3.0` (the surface is unchanged since `0.2.0`).
+
 ## [0.2.1] — 2026-10-12
 
 Patch release. **Upgrade before shipping**: on a device, `0.2.0` and earlier persisted

package/README.md

@@ -1,7 +1,7 @@
 # @chipmobilesdk/rn-payment
 
 Reusable in-app payment and entitlement capability for ChipMobileSdk-family React
-Native apps. Android only in 0.2.0, via Google Play Billing, behind a contract
+Native apps. Android only for now, via Google Play Billing, behind a contract
 that is neutral with respect to platform and store.
 
 **The package owns capability. Your app owns policy.** The package gives you a
@@ -874,9 +874,12 @@ Everything else is additive, and `0.1.0` call sites compile and behave unchanged
 A hand-written `PaymentEngine` implementation, typically a test mock, needs the two
 new methods.
 
-**No storage migration.** The schema stays at version 1: pending records were
-already persisted by `0.1.0`, and `0.2.0` only reads them. A device upgrading with
-a payment in flight sees it in the pending set at first launch.
+**No storage migration.** The schema stays at version 1, and `0.2.0` reads the
+pending records the engine already wrote. **Use `0.2.1` or later**, though: before
+`0.2.1` the store fell back to memory on every device (react-native-mmkv v4 has no
+`MMKV` constructor), so nothing — entitlements included — survived a cold start. A
+device first running `0.2.1` starts from an empty record and rebuilds it at the first
+sync, with `unknown` meanwhile, never a false `not_entitled`.
 
 **Replacing an app-side workaround.** If you kept your own "pending since" marker
 because `0.1.0` could not show a pending payment in a later session, drop it for

package/package.json

@@ -1,6 +1,6 @@
 {
 	"name": "@chipmobilesdk/rn-payment",
-	"version": "0.2.1",
+	"version": "0.3.0",
 	"private": false,
 	"license": "UNLICENSED",
 	"description": "Reusable in-app payment and entitlement capability for ChipMobileSdk React Native apps",

package/skills/sdk-rn-payment/SKILL.md

@@ -3,7 +3,7 @@ name: sdk-rn-payment
 description: "In-app payments via @chipmobilesdk/rn-payment: Play Billing one-time/consumable/subscription behind a store-neutral contract, entitlement keys with a required unknown state, pending purchases visible across sessions, guaranteed transaction finalization, per-environment production-transaction blocking. Use when selling a feature, gating on an entitlement, showing a payment still pending after a restart, debugging a purchase that returns environment_blocked or an entitlement stuck at unknown, mapping Play products to entitlement keys, or answering a Data safety question about purchases."
 metadata:
   package: "@chipmobilesdk/rn-payment"
-  packageVersion: "0.2.1"
+  packageVersion: "0.3.0"
 user-invocable: true
 disable-model-invocation: false
 ---
@@ -93,7 +93,7 @@ Unlike `@chipmobilesdk/rn-ads`, there is **no test-id substitution**: Play has n
 Call `handleForeground()` yourself on app resume — the package will not guess what
 "foreground" means for a host backgrounded by its own modal or the store's purchase sheet.
 
-## Public API (v0.2.0)
+## Public API (v0.3.0)
 
 Runtime: `createEngine` (throws `PaymentConfigError` on a bad catalog or an unsafe
 environment; everything else returns a typed result) · `createStoreProvider` ·
@@ -131,8 +131,12 @@ Types: `PaymentConfig`, `CatalogEntry`, `ProductType`, `StoreProductIds`,
 
 One compile-time change: `PaymentEventType` gained `'purchase_pending_resolved'`, so an
 exhaustive `switch` needs the case or a `default`. A hand-written `PaymentEngine` mock
-needs the two pending methods. No storage migration — `0.1.0` already persisted pending
-records. Replace any app-side "pending since" marker with `usePendingPurchases`.
+needs the two pending methods. No storage migration (schema unchanged). Replace any
+app-side "pending since" marker with `usePendingPurchases`.
+
+**Require `0.2.1` or later.** Earlier versions opened MMKV with the v3 constructor, which
+react-native-mmkv v4 does not have, so on a device nothing persisted: owners read
+`unknown` after every cold start and pending payments vanished after a kill.
 
 **Upgrade before shipping on Android.** In `0.1.0` the adapter misread `react-native-iap`
 16.x's string purchase state, so on a device a pending purchase was granted. `0.2.0`