0

I have a working TWA on Play Store (website reference) that I’m trying to update for enabling it to handle google play digital goods payments. I’ve already implemented an in-app purchase using stripe. When I submitted a simple update to the app play store images it got rejected because they noticed the missing google in-app purchase that I didn’t know yet that was required. So I’m working now on implementing it.

What I’ve made:

  1. Updated my twa-manifest.json to include billing permissions. As the first step on this article by google:
  ...
  "enableNotifications": true,
  "features": {
    "playBilling": {
      "enabled": true
    }   
  },  
  "alphaDependencies": {
    "enabled": true
  },
  ...

  1. As I use Android Studio and not Bubblewrapp to build my app, I went to this other tutorial article And followed every step in it: (a) update build gradle, sync it. (b) Create DelegationService.java and reference it on AndroidManifest.xml (c) Added the service and the activity recommended by them, also to AndroidManifest.xml.

  2. I made the app signed bundle release build and for quick testing, I’ve uploaded it to the play store internal testing

The problem:

I’ve used this generated testing link to download and install the new release on two devices: a Pixel 2 (Api 30) Emulator, and a Redmi Note 8 and as my target is to implement the play store digital goods api, I inspected the app from chrome://inspect/#devices and noticed that getDigitalGoodsService is enabled but fails when getting the Google Play Billing service:

if('getDigitalGoodsService' in window) {
    const service = await getDigitalGoodsService("https://play.google.com/billing")
}

Which the getDigitalGoodsService fails with the error:

Uncaught (in promise) DOMException: unsupported context

My hypothesis is that it isn’t working because the app is download from a testing link and not as a Play Store approved release.

Also, the URL bar is showing. But again my hypothesis to it is the same as above because I’ve made 0 changes to the digital asset links configuration that in the current production release is working fine on users' devices. But I wonder if this fact should give some explanation on why the getDigitalGoodsService fails.

Anyway, I hope I’m wrong on my hypothesis because it would mean that first I would need to release a version with the billing permissions which would be rejected because they will not see the implementation of google play billing, which is required to in-app purchases implementations. So as I don’t have an approved TWA release to debug and implement the billing, I would be stuck on the process. Unless of course, I’ve not yet noticed another way to solve it.

Any suggestions?

azabraao
  • 11
  • 2

1 Answers1

1

I've found the solution. The problem is that my Digital Asset Links configuration wasn't correctly configured. The point I was missing is that each apk/aab release might have its own sha256 fingerprint when you are testing locally or from a play store internal testing download link.

I discovered it on this doc. In the end of it they recommend this app: Asset Links Tool from Play Store.

For those who might come here in the future, remember to, using this Asset Links app, find and take your app configuration, and append it to your production assetlinks.json (on example.com/.well-known/assetlinks.json):

[
// ...your previous configuration
  {
    "relation": ["delegate_permission/common.handle_all_urls"],
    "target": {
      // your current testing asset links fingerprint took from the Asset Links app
    }
  }
]
azabraao
  • 11
  • 2