Payment Testing Practices and Pitfalls for Mobile Games: Domestic Channels, Overseas Google Play, and Web Third‑Party Payments

In the past year the author was responsible for payment testing across domestic and overseas channels, handling various payment methods and third‑party integrations, and now shares encountered problems and guidance for newcomers.

01 Payment Process Overview

For newcomers the payment process seems simple: click a product, jump to the SDK, complete payment, and receive the item. However, when issues arise it is hard to pinpoint the problematic stage, so a clear understanding of the whole flow is essential.

The diagram shows the key elements: client, server, billing platform, and channel. When a problem occurs, logs from the client, server, and billing platform are the primary sources because channel providers usually do not grant log access.

1. Billing platform logs

During a complete order flow the billing platform can trace the order through its logs. In integration and production, these logs are crucial for issues such as "payment completed but item not delivered"; ensure order ID, item ID, game ID, and channel parameters are consistent.

2. Billing product list

Products are divided into game products and channel products; one game product maps to multiple channel products. Recommendations include keeping product ID and channel product ID identical unless a special need exists, verifying the number of channel products per game product, using a price of 1 for multi‑channel testing, and aligning paid points with game design.

3. Planning table configuration

Pay attention to multi‑language/region settings, purchase limits, and compensation for over‑purchase. The planning table often varies between games and may need extensions to meet functional requirements.

4. Server billing logs

Beyond client‑side checks, server logs (especially settlement logs) can contain format or field errors that are discoverable early in testing.

02 Overseas Payment (Google Play)

Google Play is the main overseas Android distribution platform, and its payment flow differs from domestic channels. Google introduces the Play Store as an intermediate, solving regional restrictions but adding testing uncertainties.

Key differences include product parameter validation across the planning table, billing middle‑platform, and Google backend. Prices must match the billing platform’s channel product ID, and regional pricing can be set by exchange rate or locked rate.

Testing steps:

Use VPN to switch to the target region and ensure the backend region matches.

Clear Play Store cache and log out of extra accounts to avoid stale data.

For sandbox testing, log in with a sandbox account; for real‑money testing, use a regional account with a valid credit card.

Be aware of Google’s risk control which may block payments after frequent IP/device changes.

1. Product parameter validation

Parameters must be consistent in the planning table, billing platform, and Google Play configuration.

2. Google Play Store

Ensure the correct account is logged in, cache cleared, and regional settings are proper before testing.

3. Billing‑delivery configuration

Server‑side host IDs and delivery address configurations must be unique; duplicate HostIDs can cause missed deliveries.

03 Domestic Android Channel Payment

Different channels have varying integration requirements. Verify channel parameters early; mismatched historic parameters can break the flow.

Channel callbacks can be active mode, business configuration, or client configuration. Active mode resembles Google’s flow, while business configuration requires matching product IDs between the channel and billing platform. Some channels (e.g., Xiaomi) use amount‑based billing, so confirm SDK support.

04 Web Third‑Party Payment

The web payment flow mirrors client‑side payment but with the website acting as an intermediary between the game server and billing platform.

Key differences:

Purchase‑limit logic resides on the server, not the client.

Orders can be created at any time.

Multiple items may be purchased in a single order.

Testing highlights include mismatched role‑lookup fields between regions, extra field synchronization for limits and first‑charge bonuses, handling purchases during the tutorial stage, and ensuring correct multi‑item delivery.

05 Summary

The author shares insights from a year of payment testing across Google, domestic channels, and web third‑party payments:

Focus on user experience; provide fast feedback and clear communication after payment.

Read server code to understand the full payment pipeline and design finer‑grained tests.

Maintain good communication with developers, planners, billing, release, marketing, business, and web teams.

Good collaboration and thorough testing are essential for stable in‑game payment experiences.

Recommended reading:

From “Boxed Product” to “Real‑Time Service”

If I Knew Earlier, Audio Could Be Automated

Thoughts on Product Thinking for Test Development