In-app messaging

[devAshutoshkarn]

In-app messaging
If you've enabled in-app messaging with InAppMessageCategoryId.TRANSACTIONAL, Google Play will show users messaging during grace period and account hold once per day and provide them an opportunity to fix their payment without leaving the app.

Snackbar notifying the user to fix their payment
Figure 20. Snackbar notifying the user to fix their payment.
We recommend that you call this API whenever the user opens the app to determine whether the message should be shown.

If the user successfully recovered their subscription, you will receive a response code of SUBSCRIPTION_STATUS_UPDATED along with a purchase token. You should then use this purchase token to call the Google Play Developer API and refresh the subscription status in your app.

Integrate in-app messaging
To show in-app messaging to user, use BillingClient.showInAppMessages().

Here is an example of triggering the in-app messaging flow:

Kotlin
Java

val inAppMessageParams = InAppMessageParams.newBuilder()
.addInAppMessageCategoryToShow(InAppMessageCategoryId.TRANSACTIONAL)
.build()

billingClient.showInAppMessages(activity,
inAppMessageParams,
object : InAppMessageResponseListener() {
override fun onInAppMessageResponse(inAppMessageResult: InAppMessageResult) {
if (inAppMessageResult.responseCode == InAppMessageResponseCode.NO_ACTION_NEEDED) {
// The flow has finished and there is no action needed from developers.
} else if (inAppMessageResult.responseCode
== InAppMessageResponseCode.SUBSCRIPTION_STATUS_UPDATED) {
// The subscription status changed. For example, a subscription
// has been recovered from a suspend state. Developers should
// expect the purchase token to be returned with this response
// code and use the purchase token with the Google Play
// Developer API.
}
}
})

[devAshutoshkarn]

In-app messaging

[hyochan]

@devAshutoshkarn Thanks for the suggestion! This looks like a valuable feature for improving subscription recovery rates.

Could you kindly open a discussion at https://github.com/hyodotdev/openiap.dev/discussions (similar to hyodotdev/openiap#9) so that this can be added to the OpenIAP specification?

This will help us:

1. Get community feedback
2. Define a cross-platform API standard
3. Ensure consistency with other OpenIAP features

Once we have consensus on the spec, we can implement it in expo-iap.