TimeBack Store
Publish your approved app to TimeBack Store and earn revenue when parents purchase access for their kids. The Store is the monetization layer on top of the platform's app catalog — once your App is approved on the Platform, you can list it in the Store, set a price, and let parents buy directly from store.timeback.com.
What the Store Provides
TimeBack Store handles every commerce concern your app would otherwise have to build itself:
- A consumer-facing storefront at
store.timeback.comwhere parents browse the catalog, view your listing, and complete checkout. - Payment processing (Stripe under the hood) — you never touch card data or PCI scope.
- A discount-code engine so you can run promos without rolling your own redemption logic.
- An affiliate program so partners can earn a share of sales they drive to your listing.
- Entitlement writeback to the Platform — a successful purchase records
user_profileaccess against the buyer's child so your app can verify the student has paid for it at launch. - Optional post-purchase parent LTI launch — the Store hands the buyer straight into your app on the checkout success screen with the just-purchased students'
sourcedIds on the target link URI, so your landing page can greet or onboard them without a separate sign-in. - Server-to-server in-app purchases — charge the parent's saved payment method off-session against a catalog item you registered up-front, and receive a signed outbound webhook with the outcome.
- Full and partial refunds — parents can self-serve a full refund on any storefront purchase within 7 days from
store.timeback.com/account/purchases; developer apps can trigger full or partial refunds on their own storefront and in-app purchase rows via REST or the Store MCP. Every refund fires a signed outbound webhook so your app can react.
The Store is store-led: parents pay on store.timeback.com, the Store records the purchase, then the Platform records the entitlement. Your app never embeds raw Stripe primitives, and you never have to reconcile two ledgers.
Two Surfaces: MCP + REST
The Store exposes two integration surfaces you'll use depending on the task:
- MCP tools for managing your listing (e.g.
register_app,create_catalog_item,refund_purchase). Call them conversationally through Cursor / VS Code / Claude Code / ChatGPT. See MCP Setup for the full tool surface. - REST endpoints your app calls at runtime (e.g. initiate an in-app purchase, refund a purchase, list your purchases). Authenticated with the Cognito M2M client credentials (
clientId+clientSecret) thatregister_appmints for you. When you set awebhookUrlat registration time, the Store also returns a one-timeoutboundWebhookSigningSecretyou use to verify signed webhook deliveries.
Prerequisites
Before publishing to the Store you need an approved app on the Platform. The path is:
- Register your app as a draft. See Level 0: Register Your App — sign in with Google, call one tool or REST endpoint, walk away with credentials.
- Integrate against sandbox until your app is stable. See Sandbox Environment.
- Get promoted to
activetier. See App Lifecycle for the draft → active promotion gate.
Only active-tier apps can publish to the Store. The Store reads the canonical app metadata (name, description, logo, cover image, application type) from the Platform; you don't re-enter it on the Store side.
How the Store Surfaces in This Guide
| Page | What it covers |
|---|---|
| MCP Setup | Connect Cursor / VS Code / Claude Code / ChatGPT to the Store's MCP server. |
| Integration | The Store MCP tools you'll use to publish and manage your listing, plus how to verify student access at app login. |
| In-App Purchases | The POST /apps/v1/in-app-purchases REST endpoint — mint an M2M token, charge the parent's saved payment method against a catalog item, and receive the outcome via signed outbound webhook. |
| Refunds | Full and partial refund flows: parent self-serve, developer REST, developer MCP; the 7-day window; entitlement side effects; and the purchase.refunded / in-app-purchase.refunded webhooks. |
Related Docs
Level 0: Register Your App
Get your app into the Platform catalog with draft-tier credentials — the prerequisite for publishing to the Store.
App Lifecycle
How draft and active tiers work, and how to promote your App so it qualifies for Store publication.
Store → MCP Setup
Wire your AI client to the Store's MCP server so you can manage your listing conversationally.
Store → Integration
The Store MCP tool surface, plus the runtime pattern your app uses to verify a student has an active profile at launch.
Store → In-App Purchases
The server-to-server purchase endpoint, M2M authentication, and the signed outbound webhook that delivers the terminal outcome.
Store → Refunds
Refund flows across parent self-serve, developer REST, and the refund_purchase MCP tool, plus the 7-day window, one-refund-per-purchase rule, and outbound webhook payloads.
