02 / REPORTS & CHAT
Paid AI reports: connect access, follow-up chat and credits
Treat access to a saved AI report and permission to generate a new reply as separate decisions. A completed report can remain readable under its purchase terms while new AI work checks an independent allowance. Carry the selected report version into each follow-up.
Give each rule its own source of truth
A report screen needs more than an “is premium” flag. Keep the delivered report, the access entitlement and the AI operation distinct. A useful report record identifies its owner, status and version. The entitlement answers whether that user can read it. The operation records a request ID and whether generation completed, failed or was cancelled.
For example, a customer buys a weekly nutrition report with two follow-ups. The stored report is a durable result. The two replies are an allowance for new model work. Spending both replies should not erase the report if the agreed purchase terms grant continued reading.
Define the behavior before drawing the paywall
| Event | Report access | Reply allowance |
|---|---|---|
| Preview before purchase | Preview only | No paid reply is started |
| Access is verified | Delivered report opens | Use the agreed allowance |
| Follow-up completes | Unchanged | Consume one credit once |
| Follow-up fails or stops | Unchanged | Apply the agreed release or charge rule |
| Last credit is used | Keep reading under the purchase terms | Prevent new requests or offer replenishment |
| Purchase is refunded or expires | Reconcile with the access policy | Reconcile with the allowance policy |
The Table Note web demo uses a simple example policy: only a completed reply consumes one credit; a failed reply consumes none. A real provider may bill for interrupted generation, so decide who bears that cost before choosing this policy.
A follow-up needs explicit context
Send the selected report ID, version and relevant chapter through an authorized server-side lookup. Do not trust a client-supplied report ID without checking ownership. Include the user's question and only the context needed for that answer.
If a user edits a preference after receiving the report, label the difference between the original result and a new recommendation. An earlier paid result should not silently rewrite itself because today's preference changed.
Test three moments that a happy-path demo misses
- Duplicate retry: interrupt the network after generation finishes, then retry with the same operation ID. Check that the result and charge are not duplicated.
- Last-credit race: start two requests together. The server must resolve the allowance atomically, rather than trusting the displayed client balance.
- Return visit: close and reopen the app with no reply credits. Check that report access still follows its own terms.
With AppBento, A + B + C is the starting combination for this flow. The launch plan names the source code, purchase integration, backend responsibilities and checks actually included in your project.
Try the fictional report and follow-up demo. It demonstrates the interaction, not a live store transaction.
References and scope
The flow and acceptance criteria are AppBento design recommendations. These primary references cover platform boundaries; they are not endorsements or evidence of native acceptance for the web demo.