Skip to main content

In-App Purchase Concepts

Preparing your app for in-app purchase​

To use Myket In-App Purchase, add the Myket billing library to your project. The library connects your app to the Myket client installed on the user's device.

In-app product types​

You can create and manage digital products in the Myket Developer Panel. Each product has a unique SKU, a title, a description, and a price.

Products are divided into consumables and non-consumables based on how they can be purchased and used.

Consumable products​

A user can purchase and use a consumable product multiple times. Examples include:

  • Coins or gems in a game
  • Energy or fuel in a game
  • Temporary items and features

After a successful purchase, consume it through Myket. The user cannot purchase the same product again until the previous purchase has been consumed.

Non-consumable products​

A non-consumable product is purchased once and provides permanent access. Examples include:

  • Permanently removing ads
  • Upgrading an app from a trial to a full version
  • Permanently unlocking levels or premium features

Do not consume non-consumables. Myket retains their ownership in the user's account, allowing access to be restored after reinstalling the app.

Subscriptions​

Myket In-App Purchase does not currently support subscription products. For more information, contact Myket developer support at developer@myket.ir.

In-app purchase panel​

The Myket in-app purchase panel is part of the Developer Panel. Use the Products/Services section to create products and manage their details.

Product ID (SKU)​

A SKU is the unique identifier assigned to a product when it is created in the Developer Panel. It is used to identify the product in purchase requests and billing responses.

  • Each product must have a unique SKU.
  • The SKU is different from the product's display title.
  • The SKU is not shown to users during purchase.
  • A SKU cannot be changed after the product is created.

Purchase token​

A purchase token is a unique string generated by Myket to identify a purchase. It is used for operations such as consuming and validating a purchase.

Developer Payload​

Developer Payload is an optional string that you can include in a purchase request. It can carry information associated with that request and is returned to your app in the Purchase object after the payment flow. It is also available when purchase information is queried later.

  • Use a recognizable value to associate a request with a user or order.
  • Compare the returned payload with the value sent in the original request.
  • Validate purchase information on your server for stronger security.
  • Never use Developer Payload alone as proof that a purchase is valid.
tip

The developerPayload string must not exceed 800 characters.

Security note: Do not trust data returned to the client, including Developer Payload, until it has been independently validated. Verify the purchase and its association with the user.

Billing public key​

When you create an app draft in the Myket Developer Panel, Myket generates a dedicated public key. The key is used to verify the authenticity of purchase signatures. It is unique to each app and does not change when you publish a new release or update the APK.

Consuming a purchase​

When a user purchases a product, Myket records ownership. The user cannot purchase the same product again while that purchase remains unconsumed. To allow a consumable product to be purchased again, send a consume request to Myket. After a successful consume, the purchase is removed from the user's active purchases and the product can be purchased again.

Important: Consume only consumable products. Never consume non-consumables, because their ownership must remain available for restoring access.

Provisioning a product​

Provisioning means delivering the purchased product or feature to the user. For example, after verifying a 100-coin purchase, your app adds 100 coins to the user's balance. Your app is responsible for managing and recording delivery.

For consumables, the source guide's recommended flow is to verify the purchase, consume it, and then grant the product after the consume succeeds. Make provisioning idempotent so a purchase is never delivered more than once. Record processing and delivery status in your system.

Purchase and consume flow for consumables​

  1. Start the purchase flow.
  2. Receive the result and transaction information.
  3. If the purchase succeeds, validate the returned information (the Myket client library also performs client-side validation).
  4. Send the purchase to your server for verification; after verification, prepare to grant the product.
  5. Consume the purchase so Myket knows it has been processed.
  6. After the consume succeeds, deliver the purchased product in your app.

Recovering and managing unprocessed purchases​

A purchase may succeed while its consume or delivery flow is interrupted by a lost connection, app termination, or another error. Check active and unprocessed purchases when the app starts or the user signs in:

  1. Call queryInventory to retrieve the user's active purchases.
  2. Validate the purchase details and check your own processing records.
  3. Identify unconsumed consumables that have not yet been processed.
  4. Verify the transaction with your server.
  5. Consume the purchase.
  6. After a successful consume, deliver the product and record its delivery.

Do not consume non-consumables. After validating one, grant or restore access to the associated feature.

Recommendation: Make verification, consumption, and provisioning recoverable. Store each purchase's processing state using its unique ID or token to prevent lost purchases and duplicate delivery.