4.2 Google Play Billing Ecosystem - Complete Solution to Google Play Payment Implementation

In the previous section, we sorted out the ID relationship and implementation practices of Apple IAP. Next, this article will focus on the other half of the sky: Google Play Billing (hereinafter referred to as GPB). In order to obtain sustainable subscription revenue on the Android side, the four links of GPB must be connected: client tickets, Play services, Google Play Developer API, and our own server. This article unfolds in the order of "Structure → Product → Process → Monitoring". The entire article will be slightly longer than the Apple chapter because Google's definition of subscription topology and Base plan/Offer is more complex after Billing 6.

Google's official Billing architecture indicates that the client is just a trigger, and the actual settlement and bill interpretation are completed on the Play service and server([Google Developer][1])

The Three Rings of Google Play Billing

I still think of GPB as a "triple circulation". When you break down the responsibilities clearly enough, the efficiency of troubleshooting will be greatly improved.

1. Client (Play Billing Library / Play Integrity): Responsible for pulling products, initiating purchases, getting the Purchase object and handing it over to the server. At the same time, it must call acknowledge or consume after success. ([Google Developer][2])
2. Google Play Services: Play Store App, Play backend, Billing service and Real-time Developer Notifications (RTDN), responsible for deducting payment, generating purchaseToken, pushing transaction status, and allowing API query history. ([Google Developer][3])
3. Server: Receive the purchaseToken uploaded by the client, call Purchases.products/Purchases.subscriptions for verification, do acknowledge, consume, issue rights, and string together RTDN and reconciliation data.

Code example:

export const finishTransaction: MutationField<'finishTransaction'> = async ({ purchase, isConsumable = false }) => {
  if (Platform.OS === 'ios') {
    await ExpoIapModule.finishTransaction(purchase, isConsumable)
    return
  }

  if (Platform.OS === 'android') {
    const token = purchase.purchaseToken ?? undefined

    if (!token) {
      throw createPurchaseError({
        message: 'Purchase token is required to finish transaction',
        code: ErrorCode.DeveloperError,
        productId: purchase.productId,
        platform: 'android'
      })
    }

    if (isConsumable) {
      await ExpoIapModule.consumePurchaseAndroid(token)
      return
    }

    await ExpoIapModule.acknowledgePurchaseAndroid(token)
    return
  }

  throw new Error('Unsupported Platform')
}

As long as any one of these three links is in debt, it will cause accidents such as "bought but not given" and "refund not received". All IDs in GPB (purchaseToken, orderId, linkedPurchaseToken, profileId, etc.) can be classified according to these three rings. Do not mix them during debugging.

It should be noted that RTDN is configured on Google Cloud, and configuring App, adding sandbox environment, products, and subscriptions is configured on Google Play Console.

Play Console Management and Roles

Google's permission system seems simple, but it actually implies two systems: Play Console role and Payments profile permissions. To make payment work, at least the following must be met:

• Admin or Release Manager can create/publish products; ([Google Developer][4])
• Only Financial or Payments Manager roles can view income and refund data;
• A test account must be added in Play Console > Setup > License Testing, otherwise sandbox testing will be blocked;
• Merchant account (Merchant Center) must