---
name: playmos-iap
description: Add in-app purchases to an existing game using Playmos Fully Managed services, a Hybrid Managed backend, or Self Hosted checkout and processing. Includes the Hub SDK bridge, standalone UI, callbacks and verified fulfillment.
---
# Add IAP to an existing game

Read [Add IAP](https://playmos.io/docs/iap-quickstart.md) and [all game variables](https://playmos.io/docs/game-configuration.md). Public MCP provides `playmos_get_iap_guide` and `playmos://guides/in-app-purchases`; no token is needed to read them.

Inspect the game’s existing catalogue and server first. Choose ownership of hosting, payment processing and fulfillment independently:

- Fully Managed: confirm the configured service actually supports inventory and authoritative fulfillment. Hosting and a vaulted key do not enable delivery.
- Hybrid Managed: Playmos can process payments while the developer’s authenticated server verifies receipts and grants items, or the Hub can host a game that retains its existing processor.
- Self Hosted: retain the existing catalogue, processor, checkout and server. No duplicate Playmos catalogue or payment credentials are required.

Use `@playmos/sdk/checkout`. In the Hub, use `createCheckoutBridge` with the exact trusted parent origin and inspect its capabilities. Never send a wallet provider or secret into the iframe. Outside the Hub, use the [Playmos payment example](https://playmos.io/docs/examples/checkout/playmos-iap.mjs) or [existing-provider adapter](https://playmos.io/docs/examples/checkout/custom-provider.mjs). The [backend contract](https://playmos.io/docs/examples/checkout/README.md) covers saved orders, callbacks and recovery. Use `mountCheckout` for the supplied interface or the controller hooks with existing game UI.

Follow the [manual walkthrough](https://playmos.io/docs/stablecoin-quickstart.md#manual-setup) even when implementing agentically. Authenticate players on the server; freeze prices and SKUs, persist the order before signing, verify authoritative receipts and grant once. Callback retries and manual completion share one grant ledger. Keep keys server-side. Native store billing and restore remain separate provider integrations.

Verify in the running game: success, cancellation with no grant, pending recovery without a second charge, duplicate callback with one grant, and rejection of mismatched player/SKU/amount/game/network. Begin on Base Sepolia. Signing, spending, public sharing and publication require the developer’s authority. Report payment-rail proof separately from actual game inventory delivery.