Like Bits transaction, it would be great to allow Channel points to be accessible from an extension.

The idea is to not expose channel points to the extension and work the same way Bits transactions are.

This would also need the addition of channelPointSku or allow sku product to have a bits value and/or a channel Point value.

• User click on a button


• Extension fires window.Twitch.ext.points.usePoints(pointsSku)


• User validate transaction


• (if user complete transaction )OnTransactionCompleted callback is fired with receipt containing channelPoint as the currency used


• (if user cancel or don't have the channel Points) onTransactionCanceled is called

To complete it, adding a filter on the endpoint GET helix/extensions/transactions would allow developers to only get Bits transaction, channel points transaction or both.

Channel points in extensions would help people to discover features, interact with extensions more and at the same time, give a way to regulate the interaction by using channel points instead of free actions.

I was thinking, not all extensions need to be tried to a specific channel experience, and don't always interact with the broadcaster at all. Extensions like the chat translator, or maybe a TTS chat for viewers who can't read well, or visually impared, it would be great to have for users on every channel, not just channels where the broadcaster decides they want to use it. My idea is to have extensions that the view can enable on every channels, and possibly have the panel for viewer extensions be where the chat is, and possibly take up the bottom half of the screen, but same dimensions at chat, so you would have the top half of the screen be the chat, and bottom be the panel, or in a case like the translator, allow the viewer to have the panel take up the full height of chat. then the user can switch between their extensions similar to the experience on the streamer dashboard, and the drop down will be able to cycle through the extensions installed, so you can have multiple extensions running on every channel you visit.

Currently bits transactions only let you be notified of the SKU that was used.

I would like to see a more "PayPal" model or the bits usage flow.

Developers would make a POST request to Twitch with the SKU and any meta/extra data for the purchase, which would return a CheckoutID.

Developers would then pass the CheckoutID to use bits

window.Twitch.ext.bits.useBits(sku, CheckoutID);

Then on completion (or cancel) and thus the webhook/Transactions API, can return a reference to that CheckoutID and allow developers to obtain that meta data, either via API call, or returned in the onTransactionComplete JWT.

The CheckoutID created by the post request can even be the existing transactionID than the onTransactionComplete JWT returns.

Passing a CheckoutID to the useBits function would be optional, so for existing implementations there is no breaking change, and it's a optional method for developers.

Example use case: Polls, a poll with four options, with use bits to bump the vote on a given option, right now you'd need four SKU's each of the same cost with meta data you only need one SKU.

This makes it easier for developers to manage Bit SKU catalogs since they only have the one priced SKU.

Edit: This also links into RFC0011 https://discuss.dev.twitch.tv/t/rfc-0011-extension-entitlement-service/19142 but not everyone will want to use a clear entitlement flow, they just want a bit of extra meta data

To give more freedom in using Bits, having a Bits escrow system would be great.
RFC0011 ( https://discuss.dev.twitch.tv/t/rfc-0011-extension-entitlement-service/19142 ) introduced that idea but was never implemented.

What would be the possible flows:
- A viewer sends Bits, that are put "on hold"
- The streamer cancels the action asked by the viewers (because the stream is ending for example)
- After some delay, the Bits are refunded to the viewer because the transaction was not validated.

-- Viewers send Bits, that are put "on hold"
- The streamer cancels the action asked by the viewers (because the stream is ending for example)
- The Extension backend send a cancelation order to Twitch, canceling the Bits transaction.
- The Bits are refunded to the viewer because the transaction was not validated.
- If the transaction is not canceled, the Bits are sent to the streamer after the cancelation period expires.

In a practical way, it would be nice to have a way to cancel a Bits transaction before a certain limit of time.
This way we can create experiences that are safer for broadcasters and viewers because they are guaranteed to have the Bits used only when the conditions are met.
We could also use this system to handle server-side errors to refund people that used Bits something went wrong.

The "This extension can view my subscriptions list." toggle, (in Manage Extension Permissions) doesn't do a check to see if the channel that the extension is installed upon, is eligible for Subscriptions at all.

Wording should/could be changed to prevent broadcasters of type BLANK (as apposed to affiliate/partner), becoming confused.

As they'll click the toggle, run the oAuth dialog and then the toggle is still off.

On hitting the toggle, change the popup response from:

> "You have successfully authorized this extension to view your subscriber list!"

To

> "You have successfully authorized this extension to view your subscriber list! But you don't have subscribers so when if you become an affiliate we are good to go"

And/or change the wording on the toggle to indicate that the channel is not enrolled in the subscribers platform