You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Amazon App Tester subscription lifecycle limits and LAT follow-up
#522
The October 11 Amazon App Tester run proved basic purchase integration, but not the complete subscription lifecycle. We observed a difference between App Tester's local cancellation state and the original receipt returned by RVS Cloud Sandbox. This discussion records the limits and the checks needed before claiming full lifecycle support.
What we tested
On October 11, 2026, we used App Tester 3.0.200459.0_3080810, an Expo 6.0.0 consumer, and the public GitHub Packages artifact @hyodotdev/openiap-provider-amazon-example@0.0.2. A separate debuggable test app preserved the installed Martie LAT app and its data. All purchases were simulated; no payment method was added. Receipt verification used the real Amazon RVS Cloud Sandbox and a local IAPKit server connected only to DEV.
Check
Observed result
Coverage
Monthly product lookup and purchase
The real App Tester purchase activity completed successfully.
Passed in App Tester
Receipt verification and finishing
RVS-backed verification returned ENTITLED in Sandbox. The app reported success and the Tester ledger showed FULFILLED. Repeated verification produced one canonical DEV purchase row.
Passed in App Tester
Authenticated server entitlement
Binding the verified purchase to a dedicated test user granted the expected product.
Passed on DEV with a Sandbox receipt
Cancel in Tester, then relaunch and check ownership
The same ledger entry became CANCELED. The app no longer displayed the monthly subscription as Active and offered Subscribe again.
Local cancellation and ownership withdrawal observed
Reverify the original receipt after cancellation
RVS still returned HTTP 200, cancelDate: null and autoRenewing: true. IAPKit still considered that receipt entitled, and a fresh authenticated entitlement read still granted the product.
Server revocation not proven
Actual automatic renewal
Repeated RVS reads advanced renewalDate near each request time, without an independently observed renewal transaction or period transition.
Not proven
Expiry after a subscription term
No timed expiry or authoritative expired receipt was observed.
Not proven
The RVS reads were taken at 13:01:00, 13:01:34 and 13:02:26 UTC. Their renewalDate values were respectively 1791723660788, 1791723694855 and 1791723745926; purchaseDate remained 1791723615337. A changing Sandbox date alone is not evidence of a billed renewal.
Reproduce and interpret the limit
Use a debuggable app with App Tester and route SDK calls through its documented sandbox mode. Keep backend verification in RVS Cloud Sandbox.
Enable Auto Renewing Subscription in Tester and purchase a fresh monthly subscription.
Verify the receipt, finish the purchase, bind it to a test user and read server entitlements.
Cancel only that transaction in Tester's Manage Transactions screen.
Relaunch the app and check local ownership. Reverify the original receipt directly against RVS Cloud Sandbox, then perform a fresh server entitlement read.
Compare local ownership, the authoritative receipt fields and the server grant separately.
This is an observation from this run, not a confirmed production RVS defect or proof that every Tester version behaves identically. The cause of the local/cloud difference remains unknown. Tester's Cancel action also does not demonstrate the production behavior of turning off auto-renew while retaining access until the paid period ends.
Amazon's RVS Cloud Sandbox documentation says that it does not cover every production scenario and documents synthetic subscription termSku values ending in _term. The App Tester guide documents local transaction cancellation and subscription settings. Neither should be treated as a full lifecycle certification for an Appstore-distributed app.
LAT remains a separate check
On October 11, Martie LAT Test 2, code 94, was installed from the Amazon Appstore. Its checkout showed Add Payment Preference and disabled Start free trial. The test stopped without adding a payment method or completing a purchase, as requested. This was the blocker for that tester account in that run, not a requirement for all LAT testers.
That run did not verify a LAT purchase or subscription lifecycle. Later LAT receipt recovery is recorded below; renewal, cancellation, expiry and server entitlement revocation remain unverified.
What IAPKit can improve
IAPKit can extend Amazon lifecycle handling. That is separate from making App Tester produce missing authoritative store transitions.
The Amazon capability descriptor at PR #520 supported RVS validation, reconciliation and point-in-time entitlements. That revision did not claim Amazon subscription rows, renewal/refund/expiration events or inbound store notifications. Existing active receipts become due for reconciliation every 48 hours; a bounded worker runs every five minutes, so backlog and retries can delay the next check. An authenticated entitlement read also rechecks its bound receipts with RVS and fails rather than granting from an unchecked snapshot if the store cannot be reached.
When RVS actually reports a non-null cancelDate or HTTP 410, existing verification can invalidate the purchase and remove its grant. A past renewalDate alone is not treated as expiry. In this run, RVS returned neither invalidation signal after Tester cancellation, so a shorter polling interval would not resolve the observed difference.
A supported extension should:
Receive and authenticate Amazon SNS Real-Time Notifications, bind them to the correct project/app and deduplicate delivery. Treat notifications as prompts to recheck RVS, including unknown or out-of-order notification types.
Maintain canonical Amazon subscription state from verified evidence. Keep disabling auto-renew, the remaining valid period, expiry and immediate revocation distinct. Emit normalized Commerce Protocol events only for supported transitions, using the existing server-to-server developer webhook path.
Add deterministic isolated DEV fixtures for renewal, non-renewal, expiry, revocation, duplicate/out-of-order delivery and transient RVS failures. Label them as fixture tests and keep their data and credentials out of production and shipped apps.
Enable the relevant published capability flags only after implementation, conformance checks and appropriate store evidence. Complete a real LAT notification/lifecycle run before claiming that the integration is certified against Amazon.
Amazon documents RTN as supplemental to RVS and describes LAT testing for RTN. Implementing this path can improve production freshness and lifecycle coverage; it cannot turn simulated or missing Sandbox transitions into LAT evidence.
Follow-up work and acceptance criteria
Reproduce the local/cloud difference on a supported current Tester version. Check whether cancellation returns a new receipt and whether Amazon documents how that receipt should reach Sandbox RVS. Seek Amazon clarification if the difference remains.
Add a focused regression test if that investigation identifies an adapter or verification defect. Keep fixture tests labeled as fixtures; they do not replace store lifecycle evidence.
Complete an authorized LAT lifecycle run when the account can check out. Observe a renewal transaction or authoritative period transition; then disable auto-renew and verify access through the remaining valid period, expiry afterward, and removal from a fresh authenticated server entitlement read.
Test immediate revocation/refund separately where the store test environment supports it. Cancellation, non-renewal, expiry and revocation are distinct states.
Retain receipt continuity, normalized state, environment, transaction finishing and server entitlement evidence for each transition. Keep raw receipts, account identifiers and credentials private.
Do not override a server grant based only on a client-side cancellation flag or weaken RVS verification to make these tests pass. Fix a demonstrated implementation defect; keep unsupported simulator scenarios explicitly unverified.
PR #523 shipped signed SNS/RTN ingestion, RVS rechecks and canonical Amazon subscription state as a hosted beta. The Amazon guide describes its setup and limits.
As of November 7, 2026, PR #570 also verified LAT receipt recovery: Appstore build 96 recovered build 95's unfinished receipt, verified it through RVS, granted once and fulfilled it. No new purchase was made during that recovery run.
The five live checks below remain unverified. The October 11 setup had no live SNS topic and checkout was blocked by payment settings. Recheck both prerequisites before the next run; receipt recovery does not establish that a fresh subscription checkout now works.
Check
Missing prerequisite or evidence
Next step
Amazon SNS delivery
No live delivery recorded; current DEV topic setup needs checking.
Confirm the app/topic configuration and reachable DEV endpoint, then capture a signed Amazon notification and its RVS recheck.
LAT renewal
No observed renewal or authoritative period transition.
Confirm the tester can check out, then run an authorized renewable-subscription test and capture the renewal with RVS evidence.
LAT cancellation
No live auto-renew-off test.
Disable auto-renew and verify access remains through the valid term.
Elapsed expiry
No observed term ending with authoritative loss of access.
Let that term end, then check RVS and the canonical subscription state.
Server entitlement revocation
No fresh authenticated read proving the grant was removed after expiry or revocation.
Read entitlements as the bound test user after the terminal store state and confirm the product is absent.
Keep receipts and account identifiers private, and publish only redacted results. Track immediate refund/revocation separately where LAT supports it. App Tester and fixtures do not complete these live checks; keep the lifecycle beta until the evidence is recorded.
kitIAPKit (receipt-validation SaaS)amazonAmazon Appstore, FireOS and Amazon IAP integration
1 participant
Heading
Bold
Italic
Quote
Code
Link
Numbered list
Unordered list
Task list
Attach files
Mention
Reference
Menu
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
The October 11 Amazon App Tester run proved basic purchase integration, but not the complete subscription lifecycle. We observed a difference between App Tester's local cancellation state and the original receipt returned by RVS Cloud Sandbox. This discussion records the limits and the checks needed before claiming full lifecycle support.
What we tested
On October 11, 2026, we used App Tester 3.0.200459.0_3080810, an Expo 6.0.0 consumer, and the public GitHub Packages artifact
@hyodotdev/openiap-provider-amazon-example@0.0.2. A separate debuggable test app preserved the installed Martie LAT app and its data. All purchases were simulated; no payment method was added. Receipt verification used the real Amazon RVS Cloud Sandbox and a local IAPKit server connected only to DEV.ENTITLEDinSandbox. The app reported success and the Tester ledger showedFULFILLED. Repeated verification produced one canonical DEV purchase row.CANCELED. The app no longer displayed the monthly subscription as Active and offered Subscribe again.cancelDate: nullandautoRenewing: true. IAPKit still considered that receipt entitled, and a fresh authenticated entitlement read still granted the product.renewalDatenear each request time, without an independently observed renewal transaction or period transition.The RVS reads were taken at 13:01:00, 13:01:34 and 13:02:26 UTC. Their
renewalDatevalues were respectively1791723660788,1791723694855and1791723745926;purchaseDateremained1791723615337. A changing Sandbox date alone is not evidence of a billed renewal.Reproduce and interpret the limit
This is an observation from this run, not a confirmed production RVS defect or proof that every Tester version behaves identically. The cause of the local/cloud difference remains unknown. Tester's Cancel action also does not demonstrate the production behavior of turning off auto-renew while retaining access until the paid period ends.
Amazon's RVS Cloud Sandbox documentation says that it does not cover every production scenario and documents synthetic subscription
termSkuvalues ending in_term. The App Tester guide documents local transaction cancellation and subscription settings. Neither should be treated as a full lifecycle certification for an Appstore-distributed app.LAT remains a separate check
On October 11, Martie LAT Test 2, code 94, was installed from the Amazon Appstore. Its checkout showed
Add Payment Preferenceand disabledStart free trial. The test stopped without adding a payment method or completing a purchase, as requested. This was the blocker for that tester account in that run, not a requirement for all LAT testers.That run did not verify a LAT purchase or subscription lifecycle. Later LAT receipt recovery is recorded below; renewal, cancellation, expiry and server entitlement revocation remain unverified.
What IAPKit can improve
IAPKit can extend Amazon lifecycle handling. That is separate from making App Tester produce missing authoritative store transitions.
The Amazon capability descriptor at PR #520 supported RVS validation, reconciliation and point-in-time entitlements. That revision did not claim Amazon subscription rows, renewal/refund/expiration events or inbound store notifications. Existing active receipts become due for reconciliation every 48 hours; a bounded worker runs every five minutes, so backlog and retries can delay the next check. An authenticated entitlement read also rechecks its bound receipts with RVS and fails rather than granting from an unchecked snapshot if the store cannot be reached.
When RVS actually reports a non-null
cancelDateor HTTP 410, existing verification can invalidate the purchase and remove its grant. A pastrenewalDatealone is not treated as expiry. In this run, RVS returned neither invalidation signal after Tester cancellation, so a shorter polling interval would not resolve the observed difference.A supported extension should:
Amazon documents RTN as supplemental to RVS and describes LAT testing for RTN. Implementing this path can improve production freshness and lifecycle coverage; it cannot turn simulated or missing Sandbox transitions into LAT evidence.
Follow-up work and acceptance criteria
Do not override a server grant based only on a client-side cancellation flag or weaken RVS verification to make these tests pass. Fix a demonstrated implementation defect; keep unsupported simulator scenarios explicitly unverified.
Related work: example verification and recovery PR #520 and the educational community provider. Maintained FireOS apps should use OpenIAP's official Amazon integration; the community package is an integration example.
Amazon lifecycle beta follow-up
PR #523 shipped signed SNS/RTN ingestion, RVS rechecks and canonical Amazon subscription state as a hosted beta. The Amazon guide describes its setup and limits.
As of November 7, 2026, PR #570 also verified LAT receipt recovery: Appstore build 96 recovered build 95's unfinished receipt, verified it through RVS, granted once and fulfilled it. No new purchase was made during that recovery run.
The five live checks below remain unverified. The October 11 setup had no live SNS topic and checkout was blocked by payment settings. Recheck both prerequisites before the next run; receipt recovery does not establish that a fresh subscription checkout now works.
Keep receipts and account identifiers private, and publish only redacted results. Track immediate refund/revocation separately where LAT supports it. App Tester and fixtures do not complete these live checks; keep the lifecycle beta until the evidence is recorded.
All reactions