ElanoryaJewelry AI · purchases
The app will not confirm credits it cannot see on the server
The store screen does not add anything to your balance on its own. It reads the wallet the server holds, runs the purchase, reads the wallet again, and shows the credits-added confirmation only when those two reads differ. When they do not, you get a verification notice instead of a figure the app has not been able to verify.
What the screen is actually reporting
The confirmation you normally see after buying credits is not a receipt. It is the result of a comparison. The app reads the wallet the server holds for you before the purchase, and reads it again afterwards; the celebration is shown only when those two readings differ, and the balance printed in it is the one that came back from the server rather than a figure the client worked out (apps/jewelry-mobile/src/app/store/index.tsx).
That design has a direct consequence. When the app cannot prove the change, it will not show a number. Instead it shows a fixed message stating that your payment was received, that your credits are being verified on the server, and that you should check again shortly (apps/jewelry-mobile/src/i18n/catalogs/en-US.ts:195).
So the notice is a statement about the app's own evidence, not about your payment. It says the comparison did not come out positive within the app's checking window. It does not say that the credit was not created on the server.
The two ways the notice ends up on your screen
Both routes produce the same message, and the message does not distinguish between them.
- The checking window closed without a visible change
- Verification is done with a limited number of wallet re-reads. When none of them shows a change, the confirmation is never shown and the verification notice takes its place (apps/jewelry-mobile/src/app/store/index.tsx).
- The baseline reading was never taken
- If the wallet read before the purchase errored, the app has nothing to compare against and cannot prove a change, so you are shown the pending notice even if the credit did arrive (apps/jewelry-mobile/src/app/store/index.tsx).
- The message text is fixed
- It is a single catalogue string — payment received, credits being verified on the server, check again shortly — not a status generated from the server's answer (apps/jewelry-mobile/src/i18n/catalogs/en-US.ts:195).
- The client cannot report what it did not read
- What was verified on this surface is the app's waiting and display behaviour. How and when credit is written on the server is not something the store screen observes, and this page does not derive it from the notice.
What comes back to the screen after a purchase
Each row carries a different amount of proof. Nothing in this table is computed on the device.
| What appears | Where its content comes from | What it establishes |
|---|---|---|
| Credits-added confirmation | A wallet read returned by the server after the purchase | That the server-held wallet differed between the reading taken before and the reading taken after |
| The balance printed inside that confirmation | The same server response; the client adds nothing to it | That the figure is the stored balance as the server reported it |
| Verification notice | A fixed message in the app's English catalogue (apps/jewelry-mobile/src/i18n/catalogs/en-US.ts:195) | That no wallet change was observed inside the checking window, or that there was no baseline to compare with |
| Anything about the server-side payment record | Not part of what the store screen reads | Nothing — the screen makes no statement about whether the credit was created |
Reading the outcome you were given
What each screen state supports, and what it does not license you to conclude.
| Situation | Choose | Why |
|---|---|---|
| The confirmation appeared with a balance. | Take that balance as it stands. | It came back from the server's wallet read; the client did not calculate it. |
| The verification notice appeared straight after paying. | Re-open the screen later and read the balance again. | The notice is what the app shows when its bounded check did not observe a change; it is not a report on the server record. |
| The screen had trouble loading before you paid, and the notice appeared afterwards. | Treat the result as unproven rather than failed. | A failed wallet read before the purchase leaves the comparison without a baseline, so the notice can appear even if the credit did arrive. |
| The balance is still unchanged well after the purchase. | Do not read the app screen as a verdict on the payment. | Undelivered store events are held and re-attempted on the server side, and this page does not establish a delivery time or claim that every payment ends as credit. |
What happens to a purchase that could not be turned into credit
The mechanics on the server side were read from the source tree and are described here only so that the app's silence is not mistaken for a discarded payment. None of it is something you operate, request or wait on.
A store notice that fails to be turned into credit is not dropped. The event is marked failed, a shortened version of the reason is stored, the lock is released and a later attempt is scheduled. Because only controlled, shortened text is written into that reason field, the stored record carries limited diagnostic detail (apps/api/src/webhooks/revenuecat.service.ts).
Failed events are also re-processed periodically by an internal job of our own, so an event that was paid but not credited is not confined to a single delivery window. That job is not started in test environments (apps/api/src/webhooks/revenuecat.service.ts).
Re-attempts are not unlimited. A fixed budget is compiled into the code — it is not configurable, and its value is deliberately not stated here or anywhere else on this site. When the budget is spent, the event is escalated to manual review and an alarm log is written. An event that cannot be processed automatically is likewise marked so that credit is granted by hand or a refund is started; the code contains no automatic refund and no automatic compensation.
One further case is worth naming because it looks like a lost payment from the outside: if no wallet exists for you in that particular app, credit is not granted, the event counts as an error and is left for a later attempt. The lookup is keyed by user and app together, which is also the gate that stops a purchase in one app from being written into another app's wallet.
Where this misleads a seller
Each row is a reading of the screen that the screen does not support.
Reading the verification notice as proof that the credit was never created.
The notice reports the app's own comparison. Whether the credit exists on the server is outside what the store screen reads, and this page does not infer it from the message.
Paying again mid-catalogue to force the balance to move.
The message asks you to check again shortly, not to buy again. What a second payment would produce is not settled by this page.
Assuming the app will eventually announce the credit by itself.
The confirmation is tied to the purchase flow's own bounded check. Once that window has closed, reading the balance again is what shows you the current figure.
Expecting the internal manual step or the alarm to reach you.
Both are internal outcomes of the delivery path. Nothing in what was read exposes a queue, a status or a request path for a seller, so they are not something to wait on.
Treating a bounded checking window as a promise about timing.
The window bounds how long the app looks, nothing else. No statement about how long delivery takes is made here.
Before you conclude the payment failed
What the screen has already told you, and what neither the screen nor this page tells you.
- The notice states that the payment was received — that part is in the message itself.
- The absence of a confirmation means a change was not observed, not that a change did not happen.
- If the store screen struggled to load before you paid, the comparison may never have had a baseline.
- The balance shown after a purchase is the server's stored figure rather than a client calculation, so reading it again later is how you see where it stands.
- Nothing on the screen reports the server-side payment record, in either direction.
- This page does not tell you how long delivery takes, and does not state that every payment ends as credit.
What this page does not settle
- How, in what order, or how quickly credit is written on the server. Only the client's waiting and display behaviour was verified on that surface.
- That every payment eventually becomes credit. Nothing here promises that outcome.
- The number of wallet re-reads, the number of retries, any delay, interval or attempt budget. These are compiled constants and are not published.
- The internal behaviour of the stores or of the payment provider — how the payment sheet opens, how their own retries are scheduled, or which fields they send.
- Refunds, subscription renewal and cancellation as flows. The app links out to the store's account page; the flow itself is not on this surface.
- Whether any operator screen or queue view exists for events that fall to manual review. Only the database record, the log and the e-mail alarm were verified.
- Prices, credit quantities, pack or plan names and currency. This page carries none of them.
- Whether repeated processing of the same store notice is harmless. That region is not covered here, and no claim about it is made.
- That the described server-side handling is running in a deployed build. What was read is the state of the source tree, not a live verification.
Where these statements come from
The client statements were read from the Jewelry AI mobile app's store screen, apps/jewelry-mobile/src/app/store/index.tsx, together with the English message catalogue at apps/jewelry-mobile/src/i18n/catalogs/en-US.ts:195. What that reading establishes is the app's waiting and display behaviour, and nothing beyond it.
The server-side statements were read from apps/api/src/webhooks/revenuecat.service.ts in the same tree, on 18 August 2026. That reading establishes what the code does with a store notice it cannot turn into credit — marking, holding, re-attempting and escalating it — and it establishes nothing about the stores, about timing, or about a deployed release.
Questions
I paid and the app says my credits are being verified. Was the payment taken?
The message states that the payment was received and that verification is still running (apps/jewelry-mobile/src/i18n/catalogs/en-US.ts:195). Beyond that wording, the store screen reports only its own wallet readings; it does not read the payment record, so it is not the place to learn what happened to the charge.
Does the verification notice mean the credit was not created?
No. The notice appears when the app did not observe a change in the server-held wallet inside its checking window, or when the reading taken before the purchase failed and there was no baseline to compare with. In the second case the notice can appear even if the credit did arrive.
Should I buy again to make the balance move?
The notice asks you to check again shortly; it does not ask for a second purchase. This page makes no claim about what a second payment would produce, so buying again is not something it supports as a fix.
Is there anything I can do to speed up a payment that has not become credit?
Not from the app. A store notice that could not be turned into credit is marked, held, re-attempted and — once its fixed attempt budget is spent — escalated to manual review with an alarm log, all on the server side (apps/api/src/webhooks/revenuecat.service.ts). Nothing in what was read gives a seller a way to trigger, request or track any of that, so the practical action on your side is to read the balance again later.