Is your feature request related to a problem? Please describe.
Our PWA offers subscriptions to users and needs to tie the subscription to the user account on the backend. Right now we do this by sending the purchase token to the server after completing a purchase. But sometimes that's interrupted (e.g. by an internet connection error) so we have to carefully store the fact that the user made a purchase that wasn't confirmed & retry. This largely works. But it doesn't always & it can face large delays. This can be surprising to users if they purchase in our PWA and then go to use the service on another device/the web.
This is exactly what setObfuscatedAccountId is for. We could use it to associate user accounts with purchases on the backend that are delivered via Real-Time Developer Notifications (read: "webhooks") from Google Play. That way we wouldn't be reliant on the client.
Describe the solution you'd like
I imagine this would be passed in the data property of the supported instruments passed to PaymentRequest:
const supportedInstruments = [
{
supportedMethods: 'https://play.google.com/billing',
data: {
sku: "mysku",
obfuscatedAccountId: userAccountObfuscatedId
}
}
];
const request = new PaymentRequest(supportedInstruments, { /* ... */ });
Describe alternatives you've considered
I've considered building my own purchase flow with deeplinks, but that is really just a workaround to avoid this missing feature.
Is your feature request related to a problem? Please describe.
Our PWA offers subscriptions to users and needs to tie the subscription to the user account on the backend. Right now we do this by sending the purchase token to the server after completing a purchase. But sometimes that's interrupted (e.g. by an internet connection error) so we have to carefully store the fact that the user made a purchase that wasn't confirmed & retry. This largely works. But it doesn't always & it can face large delays. This can be surprising to users if they purchase in our PWA and then go to use the service on another device/the web.
This is exactly what setObfuscatedAccountId is for. We could use it to associate user accounts with purchases on the backend that are delivered via Real-Time Developer Notifications (read: "webhooks") from Google Play. That way we wouldn't be reliant on the client.
Describe the solution you'd like
I imagine this would be passed in the
dataproperty of the supported instruments passed to PaymentRequest:Describe alternatives you've considered
I've considered building my own purchase flow with deeplinks, but that is really just a workaround to avoid this missing feature.