In-App Purchases
PassAudited by ClawScan on May 1, 2026.
Overview
This instruction-only skill is coherent for building in-app purchase systems, but it naturally involves payment-provider keys, webhooks, entitlement changes, and sensitive purchase data that should be handled carefully.
This skill appears safe to install as documentation/reference material. Before using it on a production app, keep Apple/Google/RevenueCat secrets out of prompts, require review for live API changes, authenticate webhooks, protect receipt and purchase-token storage, and keep paywall language truthful and compliant.
Findings (4)
Artifact-based informational review of SKILL.md, metadata, install specs, static scan signals, and capability signals. ClawScan does not execute the skill or run runtime probes.
If used against production, the agent or developer could query subscriber information and grant or revoke paid access.
The documentation shows use of a RevenueCat secret API key for subscriber and entitlement operations. This is expected for subscription management, but it is sensitive delegated authority.
# Grant entitlement (promo) ... -H "Authorization: Bearer $SECRET_API_KEY" ... # Revoke entitlement
Keep provider secret keys in a secure backend or vault, avoid pasting secrets into chat, and require explicit human approval before making live entitlement changes.
A poorly protected webhook implementation could incorrectly grant or revoke subscription access or expose purchase-event data.
The skill includes provider webhook examples that change access based on inbound event data. This is a normal IAP architecture, but webhook origin, schema validation, idempotency, and replay protection are important.
app.post('/revenuecat/webhook', (req, res) => { const event = req.body; ... grantAccess(event.app_user_id, event.product_id); ... revokeAccess(event.app_user_id); })Validate webhook signatures or shared secrets, check event schemas, make handlers idempotent, log safely, and restrict access to webhook endpoints.
If stored insecurely, purchase tokens, receipts, and subscription history could leak customer activity or be misused to affect entitlements.
The server guidance recommends persistent storage of raw receipts, purchase tokens, and user-linked entitlement data. This is purpose-aligned for receipt verification and dispute handling, but it is sensitive persistent payment data.
3. **Store raw receipts** — for dispute resolution ... purchase_token TEXT ... user_id UUID NOT NULL
Encrypt sensitive purchase fields, minimize retention, avoid logging raw tokens or receipts, and apply strict database access controls.
End users could be pressured by paywall language if the tactics are applied without clear pricing, cancellation terms, or truthful claims.
The paywall guidance includes conversion tactics that can pressure users, while also warning not to fake scarcity. This is aligned with paywall design, but needs transparent implementation.
Loss Aversion ... "Don't lose your progress" ... Scarcity/Urgency (Use Carefully) ... "50% off - Today only" ... ⚠️ Don't fake scarcity.
Keep prices, renewal terms, trial terms, restore options, and cancellation information clear; avoid fake urgency or misleading social proof.