Checking if in-channel subscription is valid

1. The docs on roChannelStore are unreliable.


2. The blog is even more unreliable, making illogical MUST-urbative statements and then not answering questions


3. I hoped that Roku rep would answer question in the forum - not true, see viewtopic.php?f=34&t=95592 where i pointed out how off the docs on roChannelStore are - so don't hold your breath too long.

What do your experiments show?
Using test user, make a subscription then check getPurchases().
Cancel the subscription as said user, then check again - what's in getPurchases() now, what have changed?
Share your results here and we can discuss.

My experience is that the cancellation won't take effect until the end of the subscription period.  In other words, when a subscription is cancelled, getPurchases() will return valid dates for expirationDate and purchaseDate, but renewalDate will be empty until expirationDate is reached.  Once expirationDate is reached, getPurchases() will return empty values for all three as if no subscription was ever purchased.

You'd think that would be documented.

-JT

Ok I did some testing with a private channel and a test user (hopefully the only difference between a normal user and a test user is that the CC is never actually charged).

After making a test transaction for a in-channel monthly subscription product, and then canceling the subscription in the Roku control pannel, the transaction was still showing up in the list of transactions for getPurchases(). This is the behavior I was hoping for. I'm assuming that once original subscription month ends, the transaction will stop appearing in the list of purchases for getPurchases().

I did not test any of the properties related to expiration dates.

"bosborne" wrote:
Ok I did some testing with a private channel and a test user (hopefully the only difference between a normal user and a test user is that the CC is never actually charged).

Under the Occam's razor doctrine (and after some extensive testing with in-app purchases couple of months ago), it is my belief that yes - "test users" only differ from the untest ones is incurring actual charge. In fact you can switch the same user between test <-> untest by simply adding and removing them to the list.

Notice there are caveats - utterly undocumented in an inexcusable-yet-typical-of-RokuCo way - which means they could change. E.g. in my experiment, doOrder() with a test user

• Roku player UI shows $1.99 will be charged


• but when user accepts, doOrder() returns amount/total of $0.00


• however getPurchases() may later return cost of $0.99 (this last one is a bug for sure because it always returns the current product price and not what was it at purchase time - or what was actually charged)

which seems to be more of a "let-the-chips-fall-where-they-may" kind of event and not a consistent implementation