Developers

[ContraryMotion]

I'm currently implementing a pre/mid-roll ad-free subscription option to our Roku app using Roku Pay. Everything is working well in testing, but I'm a little confused about the workflow described here:

https://developer.roku.com/docs/developer-program/roku-pay/implementation/overview.md

The sequence diagram above shows calling getAllPurchases to get the currently logged in (Roku) user's purchases. It then shows a call to the validate-transaction service.

My first question is why is the call to the validate-transaction service necessary since you get all the info you need from the call to getAllPurchases?

getAllPurchases includes a status field which tells you if the purchase is in a valid or invalid state. Isn't this enough to determine whether or not to let the user access the purchases features?

Secondly, it's implied that the call to the validate-transaction service is done within the app. That call requires an API key; it seems risky to embed that within the app itself. Or is this concern not valid?

I can understand the use for the validate-transaction service on the server side. For example, the documentation here describes the logic to be implemented server side:

https://developer.roku.com/docs/developer-program/roku-pay/implementation/roku-web-service.md#valida...

Thanks for any clarification.

[renojim]

I agree; it makes no sense.  I'm probably doing something wrong, but I've never used the validate-transaction service within an app.  However, their sample does:

https://github.com/rokudev/on-device-authentication

I've always used whatever getAllPurchases returns to ascertain whether the subscription is valid, but I have very few subscriptions, so probably not enough to be able to tell if there's some case I'm not handling properly.

It's almost impossible to get anyone from Roku to chime in, but it would be nice to get some kind of explanation as to why the validate-transaction service is necessary not to mention why anything needs to be stored in the registry if getAllPurchases is called every time the app is launched.

[ContraryMotion]

Hi, renojim. Thank you for your reply.

I'm still mulling this over. If someone out there is attempting to implement Roku pay, please don't take the below as advice on how to implement it. I'm just thinking out loud.

One thing I've done is to implement Roku Push notifications.

https://developer.roku.com/docs/developer-program/roku-pay/implementation/push-notifications.md

Roku sends you quite a bit of info about subscription status and describes what you should do in response (it doesn't mention the validate transaction API).

This is useful if you offer the same subscription on other platforms, e.g. FireTV, and wish to allow users who have purchased your subscription on Roku access to the same features on other platforms.

Regarding the validate-transaction API, I'm still not sure where it fits in.

In the "Managing subscription recovery" section on the page linked below (you have to scroll down), there's quite a bit of detail about using the validate-transaction API server side.

https://developer.roku.com/docs/developer-program/roku-pay/implementation/roku-web-service.md#valida...

The idea is that you run a cron job nightly making requests to the validate transaction API for subscriptions in recovery "spread out over an approximately 6-hour period" (Roku is oddly specific about that, guess they don't want you spamming their service) to check the statuses. It describes what qualifies a subscription as being in recovery.

It says:

"If the isEntitled flag is "false", Roku has completed the payment retry cycle and canceled the subscription. Call the cancel subscription API and put the account in an "unsubscribed" state in your entitlement service so it can stop calling the validate transaction API for that subscription."

'Call the cancel subscription API'

Is that strictly necessary? For a subscription that has been cancelled already, do we have to call the API to finalize that cancellation?

Anyway, I'm wondering if push notifications and getAllPurchases are enough:

- Server side, you get the info you need through push notifications.
- App side, you get the info you need from getAllPurchases.

I'm wondering on the app side of things, if you need to check with getAllPurchases from time to time. Say someone loads your app and leaves it running for days on end. Maybe a timer set to ping every 24 hours to check would be sufficient in case their subscription status changed.

At any rate, I'm still working through this. Thanks for any replies.