Over the past year, we have seen streamers and their communities embrace Bits-powered experiences offered by Extensions.
As more Bits transactions are processed, we have heard feedback from developers that it is increasingly complex to maintain the benefits that are granted to viewers. Currently, developers are required to build and maintain an Extension Backend Service to validate transactions. However, if the developer’s EBS experiences an outage, it is difficult to retroactively fulfill the benefits to viewers who have already spent Bits. To ease this pain point, we are happy to announce a new Bits Transaction API. The API will let developers retrieve timestamped transaction history for each of their Extensions across all of Twitch. This will allow developers to “replay” the missing transactions and fulfill the relevant benefits to viewers.
What’s in the box
The API consists of a single endpoint GET https://api.twitch.tv/helix/extensions/transactions, which requires an app access token. (Refer to our Authentication documentation for more information on how to generate a token). The endpoint allows developers to retrieve historical Bits transactions that have occurred via their Extension across all channels where the Extension was activated.
There is a corresponding Webhooks functionality that allows developers to be notified of new Bits transactions.
To get started
Check out the documentation for the Extension Transactions endpoint
Check out the documentation for the Extension Transaction webhook
Let us know if you have any questions or feedback about this API below, or use the API category for more detailed inquiries
It would be cool to have a option to add a client reference id when creating the transaction. This would allow me to link a transaction (before create the transaction flow) to a specific item by just using the method useBits() and the new webhook.
Currently I still have to use the onTransactionComplete. To link the item to the transaction. However, if the developer’s EBS experiences an outage, it is difficult to retroactively fulfill the benefits to viewers who have already spent Bits.
Example:
Here is an example using an item shop with virtual items & a SKU (because the price is always the same).
The EBS creates a transaction and stores it [Client Reference ID, SKU, Item ID, Twitch Transaction ID (nullable)].
The extension calls the useBits() method and passes there the SKU + created client reference ID from EBS.
3. user pays with bits.
4. the webhook is sent to EBS and the purchase process will be finished.
Cases that occur when a transaction is cancelled (this would be a refund case or cancellation of the transaction):
The SKU + Client Reference ID do not match. If the EBS checks them together.
The SKU + Client Reference ID has already stored a Twitch Transaction ID and does not match (double purchase).
Cases If they are OK:
SKU + Client Reference ID match. Twitch Transaction ID is still null in our DB, then the transaction can be assigned and the Twitch Transaction ID can be stored.
It’s already been a thing on their list for quite a while now to have some form of state param that can be passed to useBits, which can then be included in the receipt, and now that this API is a thing including it in the API results would be essential too.
I think adding complexity to the monetization process beyond that wouldn’t be too user friendly considering the number of devs who struggle with the current monetization process.
@Dist I am not dissatisfied with the current system. It fulfils its purpose and is perfectly adequate for normal use. With more complex processes it becomes a bit difficult with this simple useBits API.
@BarryCarlyon I like Stripe’s API. There you create the transaction session on the backend side. The user confirms this, client site. And you get webhooks about the status of the transaction at your backend.