A gateway or an ad server
The smallest class. A session-open call, a notification handler and an idempotent settlement, or a tag that answers VAST. The integration is rarely the work; reconciling it with what already exists usually is.
Every platform's integration page is a wall of logos. This one is a list of verbs, because the difference between integrated, connected at onboarding and not built is the difference between a launch date that holds and one that does not.
Integrated means code exists in this platform for it and runs. Connected at onboarding means the code exists and is waiting on an account or a credential that has to be yours — a merchant key, an ad tag, a store account. Not built means there is no code, and connecting it is a piece of work with an estimate rather than a setting in a console.
A logo grid collapses all three into one impression, which is why this page does not have one. The distinction is not pedantry: it is the difference between a two-week onboarding and a two-month build, and it is the single thing most likely to move a launch date.
Where something is not built, the page says what it would take rather than leaving a silence. A silence on a vendor page is read as a yes, and that is how launch dates slip.
Every row is checkable against the module pages linked from the platform overview.
| Area | What connects today | Status |
|---|---|---|
| Content protection | AES-128 per title, with a per-request media token checked at the edge | Integrated |
| Licensed DRM — Widevine, PlayReady, FairPlay | Nothing. No licence server exists | Not built |
| Ad serving | Any ad server that answers a VAST request, pre-roll, client-side | Connected at onboarding |
| Ad reporting | Your ad server's own reporting; the console links out to it | Not built — by decision |
| Payments | SSLCommerz, which is how bKash, Nagad and cards are reached | Connected at onboarding |
| Non-BD gateways — Stripe, PayPal | Nothing | Not built |
| Carrier billing | Nothing. No charge-to-bill flow in any service | Not built |
| Identity — federated | Nothing. No OAuth, SAML, OpenID Connect or social sign-in | Not built |
| Identity — platform accounts | Accounts held by the platform, with entitlement resolved at play time | Integrated |
| Playback analytics | Per-session telemetry into a column store built for continuous ingest | Integrated |
| Object storage | S3-compatible, so any compatible store is a configuration change | Integrated |
| Delivery | Your own edge; a public CDN can sit in front of it in the hybrid pattern | Integrated |
| Notifications — push and in-app | Nothing. No device-token store and no sender | Not built |
The smallest class. A session-open call, a notification handler and an idempotent settlement, or a tag that answers VAST. The integration is rarely the work; reconciling it with what already exists usually is.
The largest class on this page. A licence server is the prerequisite for the whole row — for multi-DRM, for hardware-backed output protection and for encrypted downloads — and it changes packaging, key handling and the player on every platform at once.
Federated sign-in changes the account model rather than adding to it, so it touches account linking, entitlement lookup and every path that assumes the platform owns the identity. It is a design conversation before it is a build.
No. Content is encrypted with AES-128 per title and released against a signed, expiring token that the edge re-checks on every segment, which is real protection and is not the same thing as licensed DRM. There is no licence server in the platform, so multi-DRM, hardware-backed output protection and encrypted downloads are all a build behind that one prerequisite.
Yes, provided it answers a VAST request. The tag is configured at onboarding against your own account, so the demand and the reporting stay on your side. What the platform does not do today is anything beyond a single pre-roll.
Not today. There is no federated identity or MSISDN sign-in anywhere in the platform; accounts are held by the platform itself. Both are scoped builds, and the phone-number path is described on the carrier billing page.
It is written against the repository as read on the date under the page title, and it is checked in the same sweep as the capability spec sheet. If a row here disagrees with the spec sheet, the spec sheet is the one generated from the ledger and it wins.
Most operators arrive with an ad server, a gateway and an analytics tool they are not giving up. Send that list and we will mark it against this table honestly.