Jewelry AI, subscriptions and credit

Cancelling a plan does not reclaim the credit you already hold

Three events raise the same question: does this one take away credit that is already in the account? On the evidence read here, none of them does. A cancellation you make yourself is classified as no change at all, a payment that cannot be taken moves the entitlement into a grace state while leaving the balance alone, and a plan change that has only been announced produces nothing until a renewal actually bills.

What each event touches, and what it leaves alone

Three events, three separate answers. In none of them is credit that has already been granted taken back.

Your own cancellation: no change.: It is not classified as a refund, nothing is reclaimed and credit already granted stays (apps/api/src/webhooks/revenuecat-events.ts).
A payment that cannot be taken: access moves, credit does not.: The entitlement is set to a grace state rather than closed, and the balance is neither increased nor reduced (apps/api/src/webhooks/revenuecat.service.ts).
Separately purchased consumable credit: the billing event does not apply.: There is no grace concept for it, so the event passes over it rather than acting on it.
An announced plan change: nothing granted yet.: The change is recorded and the grant is left to the next renewal event that bills (apps/api/src/webhooks/revenuecat.service.ts).

Cancelling on your own is a stop, not a reversal

In the code that processes store notices, a cancellation is examined for the reason it carries. Only a cancellation attributed to customer support is classified as a refund. Every other cancellation, including the ordinary one a seller makes because a quiet month is coming, is classified as no change: nothing is reclaimed, and credit that was already granted stays exactly as it is (apps/api/src/webhooks/revenuecat-events.ts, source tree read 2026-08-18).

The whole distinction therefore rests on a single field. If the reason does not arrive at all, the event is not evaluated as a refund. This page does not describe how an event comes to carry one reason rather than another, and it does not describe what a refund itself does to a balance - that is a separate question and it is not settled here.

For the decision in front of you, the useful part is narrow: stopping the plan and losing the balance are not the same event, and the code does not join them.

A payment that cannot be taken moves access rather than credit

When the store reports a billing problem, access is not closed at that moment. The entitlement is moved into a grace state, and the balance is left alone in both directions - nothing is added and nothing is removed (apps/api/src/webhooks/revenuecat.service.ts).

The grace concept belongs to the entitlement, not to separately purchased consumable credit. For that kind of credit there is no such state, so the event passes over it instead of acting on it.

Two things this page will not tell you: how long that state lasts, and when access ends. Neither is present in what was read, so neither is stated here.

A plan change is announced before it is delivered

A notice that says the plan will change does not produce credit. The change has been announced, and the real transition is processed at the next renewal event - the one that actually bills. The reason is straightforward: without that rule a seller would receive credit for a period that was never paid for (apps/api/src/webhooks/revenuecat.service.ts).

Producing nothing is not the same as being discarded. The notice is written to durable storage, the product it points at is resolved, and the outcome is logged. An event that granted nothing remains distinguishable from an event that never arrived.

In practice this means the absence of new credit after a switch is the expected result at that point, and announcing the switch a second time does not bring the grant forward.

Before you cancel, switch, or let a payment lapse

Each item corresponds to one of the classifications described above.

Separate the two questions you are actually asking: whether to keep paying, and what happens to the balance you hold. The code answers them separately.
If you have already cancelled, do not treat the absence of a reversal as an error - no change is the classification for an ordinary cancellation.
If a payment failed, expect the entitlement to be in a grace state and the balance to be unchanged, and do not plan work around a duration this page cannot give you.
If you have announced a plan change, let the next renewal arrive before concluding that the change did not take effect.
Read the wording under the purchase button as the product's own statement about which credit expires with a period and which does not.
Do not read any of this as an account of what a refund does to a balance; that is outside the page.

Where this page stops

How long a grace state lasts, and when access ends. The source read here does not carry durations or thresholds.
How often a billing problem or a grace state occurs. Frequency is not something the code can be read for.
How a cancellation comes to carry the reason that makes it a refund, and what a refund then does to a balance.
The server-side truth behind the expiry wording. What was verified is that the product states it on the store screen, and where.
How credit is spent, in what order lots are consumed, or how a balance is computed. That is a different part of the system.
How a yearly commitment delivers credit over its term. Not read, and not claimed.
Amounts, prices, plan names, pack names and currency, none of which the sources behind this page support.
Whether the version of this logic described here is the one running in production. What was read is the source tree, not a deployment.

Questions

If I cancel my plan, do I lose the credit already in my account?

Not through the cancellation itself. Only a cancellation the store's notice attributes to customer support is classified as a refund; any other cancellation results in no change, so nothing is reclaimed and the credit already granted stays (apps/api/src/webhooks/revenuecat-events.ts). What a refund would do to a balance is a separate question this page does not answer.

My payment failed. Has my access closed and has my credit been taken?

The billing-problem path does not close access at that moment and does not touch the balance: the entitlement is moved into a grace state, and credit is neither added nor removed (apps/api/src/webhooks/revenuecat.service.ts). Separately purchased consumable credit has no such state, so the event passes over it. How long that state lasts and when access ends are not stated here, because the source read does not carry them.

I changed plans and no credit arrived. Did the change fail?

A change notice grants nothing on its own. The change is announced, and the real transition is processed at the next renewal event that bills, which is what prevents credit being issued for an unbilled period (apps/api/src/webhooks/revenuecat.service.ts). The notice is still written to durable storage, its target product resolved and the outcome logged, so nothing was lost by producing nothing.

Does the line under the purchase button mean my credit expires on a set date?

It is the product's own wording, stating that subscription credit expires at the end of its period and that separately purchased credit packs do not. Its presence and position on the store screen were verified (apps/jewelry-mobile/src/features/purchases/store-screen.test.tsx:436); the behaviour behind it was not read on this surface, so it should be treated as the product's statement rather than as a schedule.