Roku pay integration: what changes for your SVOD backend
Roku’s rules are blunt: a Roku app may not direct subscribers to any payment method other than Roku Pay, and Roku’s spring 2026 certification update restated it in plainer terms. Meanwhile, a US court ordered Apple in 2025 to let developers do exactly that on iOS. Existing Roku apps get no exemption. If your service bills on the web and your app still asks people to visit your site to activate, Roku Pay integration has become an architecture decision: which system decides who gets to watch. Here’s what the rules require, what they cost, and how to design around them.
What Roku requires from subscription apps in 2026
Roku groups billing and sign-in under one section of its certification criteria, now titled “Accounts and Purchases”. For an SVOD or TVOD service, five rules shape the whole integration:
- One payment method on the device. Subscription and transactional apps must include an on-device Roku Pay billing flow to pass certification.
- No steering. Apps may not facilitate or point customers to any other payment method, and any non-Roku SDK or feature connected to transactions must be disclosed. Roku can approve or reject it.
- Sign-up and sign-in happen on the TV. External web pages and off-device activation mechanisms are prohibited, whether they’re yours or a third party’s. Rendezvous linking, the familiar “enter this code at our website” flow, is reserved for TV Everywhere apps that authenticate with cable or satellite credentials.
- Plan changes happen on the TV too. Upgrades and downgrades must be completed on the device, without an external page.
- The RFI screen is mandatory. Sign-up and sign-in flows must show Roku’s Request for Information screen, which lets customers share their Roku account details with your app. Manual entry is allowed only if they decline.
The detail that catches established services is timing. Roku’s partner knowledge base states that apps are not grandfathered: if the production version doesn’t meet current requirements by the deadline, it is blocked from publishing future updates. The release that exposes an old activation flow can therefore be a routine bug fix, shipped by a team that thought billing was settled years ago. We cover the wider certification picture in what can block a Roku release in 2026.
The contrast with iOS matters if you run one payments strategy across platforms. Since a 2025 US court order, largely upheld by the Ninth Circuit in December 2025, iOS apps in the US can link subscribers to web checkout. Roku takes the opposite approach, and its distribution agreement also bars apps from encouraging purchases outside the platform, so a web-first playbook built for iOS doesn’t transfer.
The economics: 20%, 60 days and what you get for it
Under Roku’s publisher payout terms, you receive 80% of the payments actually collected from your subscribers, after taxes, credits, refunds and chargebacks. The platform keeps 20% and pays out no later than 60 days after the end of the month in which it received the money. A renewal collected in early March can therefore reach your account at the end of May.
A simple model shows the scale. Take a $9.99 monthly plan and set tax aside for clarity. Roku’s share is roughly $2.00 per subscriber per month. Fenwick’s analysis of the Epic ruling suggests that processing an external purchase can cost more than 3%, which on the same plan is about 30 cents. The comparison isn’t like for like, because the 20% also covers the store, the billing experience and payment recovery, but the difference in direct cost per subscriber is large enough to model before launch.
What Roku provides in return is a lower-friction purchase flow and payment recovery. According to the company, most customers already have a payment method on their Roku account, so a purchase takes a few presses of the remote instead of typing card details with a D-pad. When a renewal payment fails, Roku runs the recovery process: Enhanced Subscription Recovery gives a three-day grace period and then a notification cycle of up to 60 days before the subscription is cancelled. Roku’s certification tests require it for Roku Pay apps averaging more than 5 million streaming hours a month, while its recovery documentation describes it as mandatory for all Roku Pay apps since October 2024, so plan for it either way.
Whether the 20% pays for itself depends on your funnel, and there are no published conversion benchmarks. Treat vendor claims with caution and measure your own sign-up flow from launch. Above 5 million streaming hours a month, Roku already requires abandonment tracking on every page of the sign-up flow, which gives larger services a useful starting point. Smaller services can fire the same Roku Event Dispatcher events voluntarily.
Two billing systems, one entitlement source of truth
Once Roku Pay is live, some of your subscribers are billed on the TV and the rest by you. Roku Pay becomes the authoritative record of those payments, but it shouldn’t decide access on its own. Your entitlement service has to remain the single authority on who can watch, on every platform.
The official documentation assumes this model. At launch, the app reads the customer’s existing purchase from the ChannelStore node with getAllPurchases, and your backend passes the transaction ID to the validate-transaction API. The isEntitled flag in the response decides whether playback starts or the sign-up screen appears. Between launches, the platform pushes purchases, renewals, cancellations, refunds and credits to your endpoint in near real time, signed with JWT, which has been mandatory since 1 February 2024. The same web services let your backend manage the other side: cancel subscriptions, issue refunds and service credits, and change billing cycles.
Push alone isn’t enough. The documentation recommends a nightly validate-transaction batch as a backstop in case your system misses or fails to process a batch of notifications. Three design decisions follow:
- One subscriber, several billing sources. Store the transaction ID and customer ID against your own account record, tagged by billing source, rather than creating a separate “Roku user”.
- Idempotent event handling. The push feed and the nightly batch will overlap, so the same change can reach you twice. Transaction IDs are variable-length strings of up to 1,024 bytes, so don’t squeeze them into a fixed-width column.
- Daily reconciliation. Compare the platform’s view with yours on three fields: entitlement, expiry date and plan. Every mismatch is a customer who either loses access or watches for free.
The same two-system reconciliation problem appears, at larger scale, in the entitlement cutover in an OTT platform migration.
Mapping Roku Pay states to your subscriber model
Enhanced Subscription Recovery adds states that a simple active/cancelled flag can’t represent. A workable mapping:
One more rule belongs here. Products a customer shouldn’t hold at the same time, such as two monthly plans that differ only in trial length, must sit in the same product group in the Developer Dashboard. The store then blocks the second purchase instead of billing twice.
Subscribers who already pay you on the web
Your existing web subscribers still need to sign in, and they must do it on the device. The recommended sign-in flow is three screens: a landing page, the RFI screen and a password dialog. Once they’re signed in, the app can store your access token in Roku’s cloud with storeChannelCred, so the same customer is recognised on every device linked to their Roku account. Apps with authentication that average more than 1 million streaming hours a month must also support Automatic Account Link, which signs customers in automatically on additional devices.
The commercial risk is the double subscription. A web subscriber who can’t find the sign-in option presses “Start free trial” using the payment method already saved on their Roku account, and you now bill the same person through two systems. Three things reduce it. Give sign-in the same weight as sign-up on the landing screen. When a new TV purchase arrives and the customer has shared their email on the RFI screen, check it against your active web accounts, whatever payment method those accounts use. If they declined, the details they entered manually are your only match. And give support a written rule for which subscription to keep and who refunds what. Your backend can refund or cancel the TV-side subscription through the API, and your web billing system manages the rest. The harder part is agreeing the policy before the first ticket arrives. If you’re planning feature parity across other devices too, our guide to building OTT apps across platforms covers the wider picture.
Pricing, trials and win-back on Roku
You add and manage in-app products in the Developer Dashboard, so a price change on your website doesn’t carry over to the TV. Since the autumn 2025 update, SVOD apps must give every existing customer at least 15 days’ notice before a price increase and comply with local subscription law. TheDesk reported that the notice rule applies to subscription apps even where they don’t bill through Roku Pay. Build the notification into your pricing calendar rather than discovering it during review.
Larger services meet another threshold. SVOD apps averaging more than 10 million streaming hours a month must implement Instant Signup, which offers a free trial when a customer activates a new Roku device, and the rule also covers new apps expected to reach that level shortly after launch. Your Instant Signup integration must return an offer for every non-subscriber, including lapsed and cancelled ones. Apps offering Premium Subscriptions in The Roku Channel are exempt. Part of your win-back strategy is therefore set by the platform, and your offer catalogue needs a TV-specific version of your lapsed-subscriber promotion.
Testing Roku Pay before you submit
Billing is the part of the build to schedule on its own track. Testing runs through a beta channel with billing testing enabled, in-app products and registered test users. Two practical details affect how you set up the team. Roku’s test user documentation states that the test user must be the app’s root account user, and only one public or beta app per developer account can be designated for billing testing at a time. For an agency or partner team, that means agreeing early who owns the account used for billing tests. And transactions made before you complete payouts enrolment are treated as test transactions and cancelled once enrolment finishes, which is useful for rehearsal and a trap if anyone expects that data to survive.
To reset a test user’s purchase history, void their transactions from the Developer Dashboard. Before submitting, run the flows certification will run: a full purchase, a rental that expires and becomes available to rent again, and an attempt to buy a second product from the same product group, which should trigger the “already subscribed” dialog.
What Roku Pay integration won’t fix
Roku Pay handles payments, collection and a low-friction sign-up. It won’t reduce churn caused by your catalogue or pricing, and it won’t give you a complete customer identity: account details reach you only when the subscriber agrees to share them on the RFI screen.
It also sits inside a platform that competes for the same subscribers. Roku reported subscription revenue of $548m in Q2 2026, up 26% year on year, and sells Premium Subscriptions inside The Roku Channel. With FOX’s acquisition of Roku announced in June 2026 and expected to close in the first half of 2027, that’s one more reason to build the integration as one billing adapter behind your entitlement service, rather than weaving Roku-specific logic through your subscriber model.
Where to start
Integrating Roku Pay touches three systems at once: the app, your billing and your entitlement service. Start with the rules that block releases, because existing apps aren’t grandfathered. Then decide where the single source of truth for access lives, map the recovery states onto it, and write the support policy for managing customers who end up paying twice. The code is the smaller part of the work.
If you’re adding Roku Pay to an existing SVOD service or replacing an off-device activation flow, we can review your entitlement architecture and billing flows with you before your next certification submission. Talk to our experts in media and entertainment engineering.
FAQ
Yes. SVOD, TVOD and other subscription apps must include an on-device Roku Pay billing flow to pass certification, and they may not direct customers to any other payment method, a rule Roku restated in its spring 2026 update. Existing apps aren’t grandfathered: if the production version doesn’t meet current requirements by the deadline, Roku blocks further updates until it does.
Publishers receive 80% of the payments collected through Roku Pay, after taxes, credits, refunds and chargebacks, and the platform keeps 20%. Payouts arrive no later than 60 days after the end of the month in which the payment was received, so a renewal collected in March may reach you at the end of May. Ad-supported apps are paid quarterly instead.
Yes. On-device authentication lets customers with an active subscription sign in directly on the TV, typically through a landing screen, Roku’s RFI screen and a password dialog. They can’t be sent to a website to activate. Once signed in, storing your access token in the cloud means they’re recognised on other devices linked to the same Roku account.
Treat your entitlement service as the single authority on access and Roku Pay as one source of payments. Validate purchases at app launch, process the JWT-signed push notifications in near real time, and run a nightly validate-transaction batch as a backstop. Reconcile entitlement, expiry date and plan daily, and map grace, on-hold and recovered states explicitly.
Only if it’s a TV Everywhere app using cable or satellite credentials. For everyone else, sign-up, sign-in, upgrades and downgrades must happen on the device, and off-device activation mechanisms, including “enter this code on our website” flows, are prohibited. Apps that still rely on them need an on-device flow before their next update can be published.
arrow_circle_rightContact us