Introduction to Virtual Payment

Background

The basic payment capability supports direct item purchase (Direct IAP).

Terminology

• Item: A virtual item within the game, used to enhance the gaming experience or provide additional in-game services. For example: weapons, equipment, and resources in the game. In certain cases, game currency can also be regarded as a special kind of "item".

Onboarding Process

1. Payment Onboarding Process

Guide for signing the Virtual Payment Agreement: Virtual Payment Onboarding

2. Development Process

2.1 Payment Scenarios

Currently, the in-game payment scenario is direct item purchase.

The scenario where players purchase items with game currency or cash. For example: outfits, skins, etc. within the game.

2.1.1 Direct Purchase

A payment capability in which players use cash to directly purchase items/game currency. The platform notifies the developer to fulfill the order through a reliable server-side callback, and the developer is responsible for delivering the items. After the developer initiates the payment and the charge succeeds, the platform proactively pushes the item delivery message to the developer's server through the pay.notify callback, notifying the developer to deliver the item.

3. Best Practices for Minigame Payment

For games integrating the payment capability for the first time, the following recommendations apply:

3.1 Use the Direct IAP Capability for Direct Item Purchase Scenarios

With the Direct IAP capability, delivery is triggered by the platform notifying the developer. Under normal circumstances, once the charge succeeds, a server-side message push notification is sent to the developer. In extreme cases, there may be some notification delay. Special reminder:

1. The same delivery request may be sent multiple times due to network reasons. We try our best to deliver it at least once within a limited time until a clear "delivery success" response is returned.
2. For duplicate requests, the developer must ensure that delivery happens only once, and the response must return "delivery success" just as it did the first time.
3. Notification cycle: 15s/15s/30s/3m/10m/20m/30m/30m/30m/60m/3h/3h/3h/6h/6h

Must be implemented:

• Delivery messages are pushed to the developer's server as promptly and completely as possible. If a network exception occurs or a response other than "delivery success" is returned, we will retry, and the developer's server may receive duplicate delivery messages, i.e., the same order id is pushed multiple times. The developer must ensure idempotency of item delivery, so that when the same order id is notified for delivery multiple times, the item is delivered only once.
• The delivery message channel must implement request validation and properly safeguard the relevant keys to prevent requests from malicious third parties due to key leakage.

Recommended to implement:

1. Although we try our best to ensure delivery messages are pushed to the developer's server without omission, if there is a failure on the developer's side, we cannot keep retrying indefinitely. Therefore, the developer can add proactive delivery logic at a certain frequency: a. After placing an order, periodically query the order status pay.orderQuery at certain intervals, with progressively larger intervals over time (for example, later queries can be made once every 1 minute, then every 10 minutes).