App Integration (IAP-like)

This flow does not involve server-to-server communication. After a player completes a purchase, the publisher manually updates the player's balance in the game server and sends an acknowledgment to Appcharge.

Additionally, Appcharge provides a process to manage non-consumed purchases—successful transactions that have not been awarded to players for any reason. For more details on handling non-consumed purchases, see the Handling Non-Consumed Purchases section below.

High-Level Flow:

  1. Player clicks to purchase:
    The player initiates a purchase by clicking on an offer in the in-game store. This action triggers the in-game checkout SDK to begin the payment process.
  2. Create Checkout Session:
    The game server uses the SDK to request from Appcharge’s backend a session that contains all the details needed for opening the checkout. This session setup involves localization, tax calculations, and payment method preparation, all managed through server-to-server API calls.
  3. Checkout Response:
    The SDK receives a response from the backend confirming that a checkout session has been successfully created. This response includes all the necessary information to proceed with the payment.
  4. Consume:
    Once the player completes the purchase, the application sends an acknowledgment via the SDK to the Appcharge server. This indicates that the payment has been processed successfully. The game server will then need to acknowledge the order success by sending a confirmation back to Appcharge’s backend.
  5. Balance Update:
    After the acknowledgment, the game server updates the player’s balance in the game.

Handling Non-Consumed Purchases:

The non-consumed purchases list is crucial for verifying the existence of successful purchases that have not been consumed or awarded. It helps ensure that digital goods are properly delivered to players. The publisher can determine how to handle previous orders based on their preferred approach.

Developers must trigger a method in the Appcharge SDK to retrieve the list of non-consumed purchases. It is recommended that this check occurs when the store boots up, but other approaches may be used as needed:

  1. Every time the game store is opened by the player (recommended): The publisher receives a list of non-consumed purchases.
  2. Validation as configured by the publisher: The developer can configure checks for non-consumed purchases based on specific triggers or intervals.

High-Level Flow for Non-Consumed Purchases:

  1. Get Non-Consumed List:
    The game app starts by requesting a list of non-consumed purchases. This is done through the in-game checkout SDK, which communicates with the Appcharge backend to retrieve any pending purchases that have not yet been processed. The Appcharge backend responds with a list of non-consumed items.
  2. Consume:
    When a non-consumed item is processed (consumed) within the game, the SDK sends an acknowledgment back to the Appcharge backend, marking the item as consumed. This step ensures the backend knows the item has been delivered to the player.
  3. Balance Update:
    After the consumption is confirmed, the game server updates the player’s in-game balance to reflect the processed item(s), completing the flow.