Error with Bits Transaction

Extensions
1

Context:
I receive a frontend error when performing a Bits transaction to myself on my own account to test out my extension. When I submit 100 Bits, theres an error “Sorry we could not process this request” with this error on the extension

39464-d8e1b2f….js:1 [GraphQL] One or more GraphQL errors were detected on request 01JPGGQDANSCQT2V3PGH838778. IsEligible: service error

operationName: “IsEligible”

However, when I select 250 bits, and submit, it works, then when I switch back to 100 bits, I do not get the error. It happens rarely and sometimes I need to refresh the extension.

I’m wondering it it has anything to do with the fact i’m giving bits to myself?

If not, I can share some of my Bits logic

2

Update:

Currently looking into my “twitch” value which I pass in as a prop to my child, and making sure it’s always set

3

Usual suspects and questions:

Whats the state of the extension? Local/hosted/released?

Are you testing on your own channel or against another channel? (IE is the purchaser == to the broadcaster)

Do you have enough bits in your wallet to cover the transation?

Did the extension transition from not release to released and now faulting?

Whats the state of the bits product? inDev or not?

This sounds like

  • local/hosted test
  • broadcaster == purchaser

And then

  • you don’t have enough bits to cover the transaction in your wallet (even though the test transaction doesn’t consume them)

So it all works?! on both bits types.

When you say “switch” what do you mean “switch” did you call/invoke a different sku or changing the price of the sku?

If changing the price then this sounds like “transaction failed due to caching of the old/new price”

Not sure what this means wrt to this operation

For my optimal testings I always test where the purchaser != the broadcaster since thats an invalid “normal” operation anyway.

Can’t get the “use bits on your own channel” error if it’s not my own channel, so a more realistic testing scenario is advised

4

It’s in review state
I’m testing on my own channel, purchaser == broadcaster
I have enough bits to cover the transaction
The extension did not transition from not release to release and faulting
All bits are not in development mode

It all works, just not in the following situations:

  1. it doesn’t work on initial load of the page and selecting the first bits option
  2. when selecting a bits product that I can’t cover (too expensive and I don’t have enough bits), and then switching back to a lower bits amount that I can cover

what I mean by my twitch value is this:
const twitch = window.Twitch ? window.Twitch.ext : null;
Which I pass in as a prop to my child component which references this and calls the:

    if (myAuthentication.getUserId() && twitch.features.isBitsEnabled) {
                // Trigger Bits purchase
                twitch.bits.useBits(_selected_bits.toString()); // fails here

   }
5

I managed to replicate by

  • trigger useBits
  • cancel
  • trigger useBits (same sku)

But it’s not a 100% occurance rate.

tested your scenario a little and it wasn’t 100% occurance (but not a complete matching test)

Speculation the first: Possible some sort of race condition somewhere I’d guess.

Speculation the second: Most cases I don’t expect this to effect many viewers/purchases since they don’t tend to get half way thru “checkout” abanadon and go around again but I don’t have metrics to support that, and/or explains why it’s not been noticed before.

You should file this as a github with the repro steps - GitHub - twitchdev/issues: Issue tracker for third party developers.

as an aside:

Not sure why you are toString-ing here as skus should always be strings. But I imagine you are setting your sku to be a the number cost and toString~ing?

6

Hey everyone—I’ve done some more digging into the intermittent useBits() failures, and I’ve resolved the behavior. The issue wasn’t the SKU itself, but a synchronization issue between the Twitch SDK state and the UI trigger.

For anyone else dealing with this, here is the mental model and the fix I’ve implemented:

The Mental Model:

  • isBitsEnabled = Permission/Readiness Gate: Treat this as an asynchronous state-sync requirement. Even if Twitch.ext.bits is defined, the feature-flag readiness is not instantaneous upon load or state changes.

  • IsEligible = Purchase Preflight: This is an internal check by Twitch. Rejections here often occur if the user/channel state doesn’t meet requirements—such as active transaction cooldowns—which can cause subsequent useBits calls to fail immediately if the UI allows re-triggers too quickly.

The Solution: I stopped “hammering” useBits() and implemented a strict UI gate:

  1. Poll for readiness: I track isBitsEnabled in my component state and keep the “Go!”/Purchase button disabled until this flag explicitly returns true.

  2. Handle Cooldowns: I treat the useBits flow as a state machine. If an error is returned (including cooldown-related rejections), I force the UI to lock the button and wait for a clear state, preventing repeated invalid purchase attempts and reducing
    Twitch-side eligibility failures.