OTT payment gateway integration: 96 gateways behind one checkout
OTT payment gateway integration on Flicknexs: 96 gateways including Stripe, Razorpay and PayPal, store billing in the apps, no commission.
Flicknexs routes web subscriptions and pay-per-view charges through any of 96 gateway integrations while the mobile apps bill through Apple and Google.
Trusted by industry leaders
50+ OTT platforms powered by Flicknexs
Quick answer: OTT payment gateway integration connects a streaming service's checkout to the processors that charge viewers for subscriptions and pay-per-view. Flicknexs ships 96 gateway integrations in its payment service, with Stripe, Razorpay and PayPal covering subscriptions and one-time charges, while the iOS and Android apps bill through the stores as their policies require.
Flicknexs provides payment gateways as part of its white-label OTT platform. Flicknexs routes web subscriptions and pay-per-view charges through any of 96 gateway integrations while the mobile apps bill through Apple and Google.
Why the gateway list matters more than the gateway count
The gateway is the part of a streaming service viewers never think about until it fails. A card declined in one country, a currency the processor does not settle, a subscription that renews twice: each one is a support ticket and, often, a lost subscriber. Operators choose a platform partly on which gateways it can talk to, because the right gateway for a service in Mumbai is not the right gateway for one in Manchester. Flicknexs carries 96 gateway integrations in its payment service so that choice is yours rather than the platform's.
Counting integrations is easy; knowing what each one does is what matters. A gateway that can take a one-time payment is not the same as one that can create, update and cancel a recurring subscription, schedule a plan upgrade, or accept a promotion code. This page states what the three most used gateways in the platform code do for subscriptions and for one-time charges, how verification works when the viewer returns from checkout, and how the mobile apps bill through the stores instead. It is written from the code rather than from a brochure.
The security model follows the gateways' own. Stripe's payments documentation describes a hosted checkout in which card details are entered on a page Stripe serves, so the operator's platform never handles the card number; Razorpay and PayPal work the same way through their hosted flows. Flicknexs uses those hosted checkouts and verifies the result server-side when the viewer returns, which keeps card data out of the platform and out of your compliance scope. The gateway charges its published fee; the plan fee is flat.
What the gateway integration does on Flicknexs
Every row below is in the platform code. The three named gateways are the ones with full subscription support that most operators connect first.
96 gateway integrations
The payment service holds 96 gateway integrations; you connect the ones your regions need.
Stripe subscriptions
Recurring plans, scheduled plan upgrades, one-time pay-per-view charges and promotion codes at checkout.
Razorpay subscriptions
Subscriptions created, fetched, updated and canceled through Razorpay, plus one-time orders for pay-per-view.
PayPal billing
Billing subscriptions for plans and checkout orders with capture for one-time purchases.
Server-side verification
On return from checkout the platform re-checks the session with the gateway before granting access.
Plan currency
Each plan sets the currency charged, so it bills in the currency you set.
Store billing in apps
iOS sells through StoreKit and Android through Google Play Billing, mapped to your plans.
Revenue reports
Subscription and pay-per-view revenue reported by month across every connected route.
Source: Flicknexs platform documentation and architecture specification, 2026-09-03.
How OTT payment gateway integration works on Flicknexs
Six things to understand before you connect anything: what the count means, what each main gateway does, how payment is verified, and how the apps differ.
What 96 integrations means
The payment service contains 96 gateway integrations, each a module that knows how to create a charge or subscription with that processor and read the result back. You do not run all 96; you connect the ones your audience uses and the rest stay dormant. The number is from the platform code, not a marketing figure, and it is why this page says 96 rather than a rounder claim.
Stripe: subscriptions, upgrades and one-time charges
Stripe is the most complete integration. It creates recurring subscriptions for plans, hands plan upgrades to Stripe as scheduled changes so the viewer is not double-charged, takes one-time pay-per-view charges, and accepts Stripe-hosted promotion codes at checkout. The currency for a subscription is taken from the plan. When the viewer returns from the Stripe checkout the platform re-checks the session server-side before it grants access.
Razorpay: recurring billing for India
The Razorpay integration creates, fetches, updates and cancels subscriptions through Razorpay's subscription API, and creates one-time orders for pay-per-view. Operators billing in rupees with UPI, net banking and local cards typically connect Razorpay for the web checkout. Coupons do not apply on the Razorpay route; offers there are run by adjusting the plan price for a period.
PayPal: billing subscriptions and checkout orders
PayPal covers plans through billing subscriptions and pay-per-view through checkout orders that are captured after the viewer approves them. It suits audiences that prefer a wallet to a card, and services that sell to viewers in countries where card penetration is low. As with Razorpay, promotion codes are not part of the PayPal route.
Verification on return, not webhooks
Stripe verification is a server-side re-check of the checkout session when the viewer's browser returns to the site. The platform asks Stripe whether the session is paid before it activates the plan or records the rental. It does not rely on Stripe webhooks, so there is no endpoint to expose or webhook secret to rotate; the trade-off is that a viewer who closes the tab before returning may need to reload.
The store routes in the apps
The iOS app sells subscriptions and pay-per-view through StoreKit; the Android app sells through Google Play Billing with real-time developer notifications decoded server-side and purchase tokens verified against Google. Product IDs are mapped to plans and per-title prices in the admin. These routes exist because the store policies require them, and they run alongside the web gateway rather than replacing it.
How to set up a payment gateway in the Flicknexs admin
Five steps from choosing a processor to mapping store products. Use test keys until the last step.
- 1
Choose the gateway for each region
Decide which processor will serve which audience before you touch the admin. A common pattern is Stripe for card markets, Razorpay for India and PayPal where wallets dominate. Consider settlement currency, local payment methods and whether you need subscriptions or only one-time charges on that route.
- 2
Enter the credentials
Open the payment settings and add the API keys for each gateway you will use. Use test keys first. Each integration reads its own settings, so a mistyped key on one gateway does not affect another. Keep the live keys in a password manager; the admin stores them but you should hold the originals.
- 3
Create plans with the right currency
Add subscription plans with name, price and interval. The currency charged is taken from the plan, so a service billing in two currencies creates two plans rather than one plan with a conversion. Per-title pay-per-view prices are set on the title, per quality level, in the same currency as the route.
- 4
Run a purchase on every route
With test keys, buy a plan and a rental through each gateway you connected. Confirm the viewer returns to the site, the server-side re-check passes and access is granted. Then switch to live keys and buy once more with a real card, refunding it from the gateway dashboard afterwards.
- 5
Map the store products
If you ship the mobile apps, create products in App Store Connect and Google Play Console for each plan and per-title price, then map the product IDs in the admin. For Android, set up the real-time developer notifications topic so renewals and cancellations reach the platform.
Limits and what the integration does not do
These are the boundaries that surprise operators after launch. Each is stated as it stands in the platform code.
No Stripe webhooks
The Stripe integration verifies by re-checking the checkout session server-side when the viewer returns. It does not consume Stripe webhook events. Events that happen away from the checkout, such as a card failing on a later renewal, are visible in the Stripe dashboard and reflected when the subscription state is next read, not pushed to the platform in real time.
Coupons on Stripe only
Promotion codes and the admin coupon setting apply on the Stripe-hosted checkout. They do not apply on Razorpay, PayPal or any of the other integrations, and not inside the store-billed apps. The coupons and discounts page covers this boundary and the per-plan toggle that decides which plans accept a code.
Apple receipt validation is not implemented
On iOS the purchase is made through StoreKit and recorded from the app; the platform grants access from that record. Server-side receipt validation and App Store Server Notifications are not implemented. Android, by contrast, verifies purchase tokens against Google and decodes real-time developer notifications for renewals, cancellations and expiries.
Roku billing is a per-build item
Roku Pay is not in the platform code. The Roku channel is built per customer as an add-on and Roku Pay integration is scoped inside that build on request. Web and mobile subscribers sign in on Roku with a code instead of buying again. The Roku Pay page states the arrangement plainly.
No automatic gateway selection
You can connect several gateways, and each connected one is a route the web checkout can offer. The platform does not pick a processor per transaction on its own; which routes a viewer sees is your configuration. If you serve two regions with two gateways, that is two routes you configure and test, not one route that decides for you.
A worked example: a regional news channel billing in two markets
Take a regional news channel with a home audience in India and a diaspora audience in North America and the Gulf. It sells one monthly plan and a handful of pay-per-view specials around elections and festivals. In the admin it connects Razorpay for the home market, where viewers pay by UPI and local cards in rupees, and Stripe for everyone else, billing in US dollars. It creates two plans, one per currency, because the currency charged is taken from the plan rather than converted at checkout.
The home-market checkout runs through Razorpay: subscriptions are created and, when a viewer cancels, canceled through Razorpay's own calls. The diaspora checkout runs through Stripe, where a launch promotion code takes a share off the first invoice; the same code is not offered on the Razorpay route, so the channel adjusted the rupee plan price for the launch month instead. Both routes verify the payment server-side before the plan activates on the viewer's account.
The mobile apps bill through the stores. The channel created the monthly plan and each special as products in App Store Connect and Google Play Console and mapped the product IDs in the admin, so an Android viewer who renews through Google keeps access after a real-time developer notification is decoded. The revenue report by month shows subscription and pay-per-view income across Razorpay, Stripe and the stores in one place, which is what the finance lead asked for.
Pre-launch checklist for payment gateways
- Confirm each plan’s currency matches the settlement currency of the gateway that will charge it.
- Buy a plan and a rental with test keys on every gateway you connected and confirm access is granted on return.
- Make one live purchase per gateway with a real card, then refund it from the gateway dashboard.
- Cancel a test subscription from the viewer side and confirm the gateway shows it canceled.
- Trigger a plan upgrade on Stripe and confirm it appears as a scheduled change, not a second subscription.
- Map every App Store and Google Play product ID before you submit the apps for review.
- Set up the Google Play real-time developer notifications topic and confirm a test renewal reaches the platform.
- Decide where promotion codes will run, since they apply on the Stripe checkout only.
- Note the gateway’s published fee for each route so your revenue report reconciles against payouts.
- Store live API keys in a password manager and rotate them if a team member with admin access leaves.
How the gateways work with the apps and the paywall
The gateway is the billing route; the paywall is the rule it serves. The video paywall page covers what a plan grants, how per-title prices are set per quality level and how rental windows behave; none of that changes with the gateway you choose. What changes is the checkout the viewer sees, the currency and payment methods on it, and whether a promotion code can be typed there.
The device apps each have a billing route of their own. The web checkout uses the gateway you configured. The iOS app uses StoreKit and the Android app uses Google Play Billing, described on the Apple in-app purchases and Google Play billing pages, with product IDs mapped to the same plans. Android TV and Fire TV do not sell; the viewer signs in and inherits the plan. Roku, Samsung, LG and Apple TV apps are built per customer as add-ons.
The Stripe integration page, the Razorpay integration page and the PayPal integration page each go one level deeper on the calls their gateway supports. Read the one for the gateway you will bill through first, and the coupons and discounts page if you plan an offer, because the coupon boundary is the most common surprise after launch.
Which plan includes payment gateways
Standard layers
Every payment gateway integration is part of every plan; there is no per-gateway charge and no tier that limits which of the 96 you can connect. Plans are flat fees and Flicknexs takes no commission on your revenue; payment-gateway fees are between you and your gateway. See our pricing page for current plan and pricing details. F1 Standard is the web-only plan, with 300 GB of storage and 20 TB of bandwidth yearly; see our pricing page for current plan and pricing details.
Pricing & billing
F1 Standard includes 300 GB of storage and 20 TB of bandwidth yearly for website streaming; see our pricing page for current plan and pricing details. F2 Super includes 300 GB of storage and 20 TB of bandwidth yearly, and adds native Android and iOS mobile apps; see our pricing page for current plan and pricing details. F3 Premium includes 1 TB of storage and 10 TB of bandwidth monthly, and adds Android TV and Fire TV apps; see our pricing page for current plan and pricing details. F4 Enterprise includes 2 TB of storage and 20 TB of bandwidth monthly and adds dedicated support to everything in F3; Samsung, LG, Roku and Apple TV apps are add-ons on any plan. See our pricing page for current plan and pricing details.
Annual savings
TV apps are available as add-ons on any plan, allowing you to expand your reach to more devices; see our pricing page for current plan and pricing details. Yearly billing on F1 to F4 costs less per month than monthly billing; see our pricing page for current plan and pricing details. The gateway's own processing charge is the gateway's published fee, and the gateway deducts it before payout, separately from your plan.
Conclusion: what to do next
Already on Flicknexs
If you are already on Flicknexs, open the payment settings and confirm every connected gateway has live keys and a completed test purchase behind it. Then check the store product mapping against the plans that exist today; a plan added after the apps shipped is the usual cause of a store purchase that grants nothing to the viewer.
Choosing a platform
If you are choosing a platform, ask the vendor for the gateway count from their code and for what each gateway does: subscriptions, upgrades, one-time charges, coupons. Then run a purchase on a trial account through the gateway your region uses, cancel it, and watch what the platform records. That sequence exposes more than any comparison table will.
Before a rights call
Read the companion pages next. The Stripe integration page covers subscriptions, scheduled upgrades and server-side verification; the Razorpay integration page covers recurring billing for India; the PayPal integration page covers billing subscriptions and captured orders. The video paywall page explains what each plan and price actually grants once payment succeeds.
Frequently Asked Questions
Everything you need to know about payment gateways on Flicknexs.
The payment service contains 96 gateway integrations. That figure is taken from the platform code on the date at the top of this page, not rounded up. You connect the ones your audience uses; Stripe, Razorpay and PayPal are the ones with subscription support that most operators start with.
Yes. You can connect several gateways at the same time, and each connected gateway is a route your web checkout can offer. The usual pattern is one gateway per region, such as Razorpay for India and Stripe elsewhere, with a plan in each currency because the currency is taken from the plan.
Plans are flat fees and Flicknexs takes no commission on your revenue; payment-gateway fees are between you and your gateway. See our pricing page for current plan and pricing details. The gateway's own processing charge is the gateway's published fee and is deducted before payout.
In the platform code, Stripe creates subscriptions and schedules plan upgrades, Razorpay creates, fetches, updates and cancels subscriptions, and PayPal creates billing subscriptions. Many of the other integrations handle one-time charges; check the specific gateway with the team before you plan recurring billing on it.
By re-checking the checkout session server-side when the viewer returns to the site. The platform asks Stripe whether the session is paid before it activates the plan or records the rental. It does not use Stripe webhooks, so there is no webhook endpoint or secret to manage.
The currency charged is taken from the plan. To bill in two currencies you create two plans, one per currency, and offer each to the right audience. The gateway settles in the currencies it supports, so check that before you create the plans and set the prices.
No. Promotion codes and the admin coupon setting apply on the Stripe-hosted checkout only. Razorpay, PayPal and the other integrations charge the plan at list price, and the store-billed mobile apps do not accept codes. Operators on other gateways run offers by adjusting the plan price for a period.
Through the stores, as their policies require. The iOS app sells through StoreKit and the purchase is recorded from the app. The Android app sells through Google Play Billing; real-time developer notifications are decoded server-side and purchase tokens are verified against Google. Product IDs map to plans in the admin.
No. Server-side receipt validation and App Store Server Notifications are not implemented. The iOS purchase is made through StoreKit and recorded from the app, and access is granted from that record. Android verification against Google is implemented, including renewal, cancellation and expiry notifications.
Roku Pay is not in the platform code. TV apps are available as add-ons on any plan, allowing you to expand your reach to more devices; see our pricing page for current plan and pricing details. Roku Pay integration is scoped inside that build on request, and web or mobile subscribers sign in on Roku with a code without buying again.
No. Each gateway's hosted checkout collects the card details on a page the gateway serves, and the platform receives a result to verify rather than the card number. That keeps card data out of the Flicknexs database and out of your compliance scope for card handling.
Yes, for new purchases: connect the new gateway and route new checkouts to it. Existing subscriptions stay with the gateway that created them until they are canceled or re-created, because the recurring agreement lives at that gateway. Plan the switch around renewal dates.