Is there any implementation documentation or sample code available for implementing in-app purchases - specifically subscriptions - within a channel?
Our team currently has some documentation that includes some example UI flows, but it would be great to have some sample code that we could use as a base for our own implementation.
This might help: http://blog.roku.com/developer/2013/06/ … -channels/
Thanks, that is helpful!
Another question: how would you go about making a PIN entry screen like the one shown in the UI guidelines?
[upload|oMM5CxSxEzN3R4oG1FGB6g==]
The PIN entry screen is part of the firmware - it will automatically show when a user attempts to make a purchase, if they have a PIN set in their account. We also have a component:
http://sdkdocs.roku.com/display/sdkdoc/roPinEntryDialog
That can be used to enter a PIN if your channel needs to use one for its own purposes but it is not part of the Roku Billing Services purchasing process.
Thanks. It seems to work as you describe.
One more question:
I’m looking to validate an order on our server using the web API after the purchase has been made. However, to do this I need the order’s transaction ID. What is the best way to retrieve this transaction ID? I assumed that DoOrder() would return the order’s information, including the transaction ID, which I could then pass to our server. That doesn’t seem to be the case though, as the method simply returns a boolean value indicating whether the purchase was successful.
Now I see that the Roku receives a roChannelStoreEvent response after the purchase is complete that contains the items that were ordered. However, this response only contains information about the items that were ordered and doesn’t provide the actual transaction ID of the order. Am I looking in the wrong place?
The event that is fired after making a purchase contains an attribute called PurchaseID. This is how the BrightScript events sends the transaction id. It is a bit confusing that the names are different.
“RokuRobB” wrote:
The event that is fired after making a purchase contains an attribute called PurchaseID. This is how the BrightScript events sends the transaction id. It is a bit confusing that the names are different.
Is it possible that legacy devices on the 3.1 firmware are filtering/ignoring the purchaseId attribute? It seems to happen even when testing locally with the store.FakeServer function using a valid purchaseId at the corresponding PlaceOrder.xml file inside csfake folder. It only happens in 3.1 fw. Perhaps the attribute is simply being ignored, but it would be possible to manually parse the response from the roChannelStoreEvent without relying on GetResponse()?
FYI in-channel purchases and subscriptions are not really supported on firmware 3.1, only purchase or subscription of the channel itself.
“RokuJoel” wrote:
FYI in-channel purchases and subscriptions are not really supported on firmware 3.1, only purchase or subscription of the channel itself.
Wait, wat?
Could you explain more on this, please. Are you saying that roChannelStore is not in fw3 - or is there something else? I just checked and createObject returned me <Component: roChannelStore> on 2050 player.
roChannel store exists on 3.1, and in-app purchases (one time purchase) can be done on 3.1, as well as outright purchase, and in-place upgrade to a Premium channel (where the pro channel replaces the Lite channel).
However roChannelStore does not return the full set of data that you need to properly implement a monthly or yearly subscription to a content item within the channel, which we call in-channel subscriptions.
In Channel subscriptions have never been tested on 3.1 by our QA team and officially, this capability does not exist on that platform.
That being said, I believe it may be technically possible to use the WebAPI as a work around to get the information needed to properly implement an in channel subscription.
“RokuJoel” wrote:
roChannel store exists on 3.1, and in-app purchases (one time purchase) can be done on 3.1, as well as outright purchase, and in-place upgrade to a Premium channel (where the pro channel replaces the Lite channel).
Oh good - phew! - i was startled by the “in-channel purchases … are not really supported on firmware 3.1”. I guess you mis-spoke then and reading further explanation, in-channel purchases are ok but subscriptions may not be. Which is fine with me, what i cared about is “freemium” (i.e. your “in-place upgrade to a Premium”). Thanks.
