Integrating Your Roku Channel With Roku Pay

As someone new to Roku development, building channels on the platform can be quite the love/hate relationship. Roku’s scripting language, BrightScript, appears limited and somewhat primitive on the surface when compared to other modern frameworks. However, this also makes it efficient and straightforward to implement.

Although simplistic in structure, there are still challenges to be had — one being, integrating your channel with the Roku Pay store. The documentation around testing in-app purchases and store commands is fairly brief, so I wanted to highlight some insights I gained in my first experience with this process.

Enable Local Billing Testing First

You may have figured out that invoking commands to the Roku store does not work in locally sideloaded channels by default. This can be a huge headache when debugging changes if you aren’t familiar with the process of Roku billing testing. To use a channel for billing testing, you must meet all of the requirements noted in the documentation :

• The channel must be the only one in the developer’s account designated for billing testing.
• The “billing testing” channel may only be used by the root account user .
• The root account user must be designated as a Test User.
• The Test User’s Roku account must be linked to the Roku device on which the channel is sideloaded.
• The channel must be sideloaded on the Roku device.

The main takeaway here is that an administrator account will not work — you must use the account that created the channel (root account). In a situation where you cannot access the root account, I’ve seen other developers create private channels under their personal account in order to satisfy this requirement. Shout out to the Roku developers Slack group for the tips on this one. I highly suggest joining the group if you are new to Roku development.

Get Familiar With The ChannelStore Node

Most of what takes place in a channel with Roku Pay revolves around the ChannelStore node. This SceneGraph node is responsible for invoking commands that retrieve and send data back to Roku as well as populating the necessary responses from those commands.

For instance, the doOrder command is responsible for processing a purchase, which is a crucial piece of Roku Pay integration. It can be called by simply creating an order with a product node that has a couple required fields.

This varies slightly if you need to process an upgrade or downgrade transaction. The transaction should be determined as an upgrade or downgrade based on if the user is paying more or less for the new product. With that logic in mind, an action parameter is added to the order node prior to invoking the doOrder command.

Implement Roku Pay Web Services

Modifications to a user’s subscription outside of upgrading and downgrading aren’t as straight forward. Canceling or refunding subscriptions along with updating the billing cycle or issuing service credits all happen within the Roku Pay web services .

I won’t go into detail here as the official documentation is actually pretty thorough regarding the API endpoints. But, I wanted to call out that these actions function outside of the ChannelStore node and network requests will need to be built independently to handle them.

In Summary

There are usually some quirks involved with Roku development and integration with Roku Pay is no exception. My hope is this helps clarify some of the process which might not be obvious at first glance.

• Rob Abbott

  Software Engineer

  More from Rob