Game and environment
Establish the intended game and any relevant platform, server or region. Do not let a reused form imply that all games accept the same recipient information.
Game top-up API
Evaluate a direct game-account credit journey for a storefront, wallet or rewards product. APISMA’s private access review starts with your intended audience, account-credit use and business scope.
Recipient identification
An identifier can look valid while referring to the wrong account or server. Design a clear confirmation step using only the information the approved integration can actually validate.
Establish the intended game and any relevant platform, server or region. Do not let a reused form imply that all games accept the same recipient information.
Use the exact identifier requirements from the approved reference. Explain where the customer can find the identifier and distinguish it from a display name or nickname.
Show the customer’s supplied context back to them before proceeding. Only display a verified account name if the actual integration supports that check; an entered name is not independent validation.
After confirmation
Direct account-credit journeys need a deliberate pending experience. Define the message, review route and safe repeat-action behavior before implementing the happy path.
Preserve the customer’s safe reference and submitted context. Explain that the result is being checked instead of silently resetting the form.
A lost response alone does not show whether account credit occurred. Follow the agreed status or investigation method before inviting another action.
Identify who can investigate the destination and outcome. Keep player information and sensitive account context out of public support channels.
Where the model fits
Describe the point where a customer or reward recipient chooses direct account credit. These are planning scenarios, not confirmed APISMA product or delivery capabilities.
The player selects a top-up and supplies the destination account context. Your storefront needs a clear confirmation and support experience.
Separate the customer’s wallet decision from the destination top-up outcome. Define how your product communicates when those steps do not resolve together.
The reward recipient needs to know which account receives the value. Do not imply that a top-up can be redirected or reversed after processing.
A form that asks only for a player ID may omit a condition the selected game requires. The right planning question is which fields identify the destination for that game, not whether the ID contains the expected number of characters.
Confirm the actual requirements and any available validation privately before building the input form.
Common questions
This public guide does not confirm games, platforms or account fields. Bring your intended game and market needs to qualification, then verify the requirements for the agreed scope.
Do not assume it can. Applicable correction and refund conditions need confirmation in the private agreement. The interface should help the customer verify the destination before proceeding.
No general retry rule can establish that this is safe. Preserve the original business action and follow the approved duplicate-handling and recovery contract.
Provide the company and work contact, explain the direct account-credit journey, select the category and estimate monthly volume. Submission does not issue credentials or guarantee approval.
Select game top-ups in the form and share your company, work contact and expected volume. Prepare game, audience and market questions for the follow-up; do not submit player records or credentials.
Submitting a request does not create an account or guarantee approval.