Unpredictable failure mode due to Stripe.apiKey not being set and lazy-loaded collections

Java Version: 11 Stripe-Java Library version: 19.33.0

This may not be a bug exactly, but it looks a lot like one from here.

When Stripe.apiKey is not set, the Stripe Java API works fine most of the time, so long as a RequestOptions containing the API key is supplied with every API call.

However, when a webhook endpoint triggers a lazy-load of a collection, then the Stripe call fails with com.stripe.exception.AuthenticationException: No API key provided... because Stripe doesn’t have an API key to use.

Whether a collection is lazy-loaded is not easily predictable.

In my case I found that my webhook only failed when the Payment Intent payload it received had more than one charge (i.e. one failed charge and then one successful charge). With only a single charge then lazy-loading was not triggered because the single charge was included in the webhook payload, but with two charges then only one of the two charges was included and so when the webhook code iterated over all the charges then a lazy-load was triggered.

Luckily this behaviour was found during testing, but it could easily have been missed. The API docs don’t make it clear that you really to need to set Stripe.apiKey even if you also set the API key in a RequestOptions (https://stripe.com/docs/api/authentication)

I’m not sure how to fix this. Perhaps Stripe should fail to do anything if Stripe.apiKey is not set, so that this coding error is detecting as soon as possible?

[kamil-stripe]

The fix has shipped with v21.

[richardm-stripe]

This definitely feels like a trap to me. I agree it’s worth considering throwing an exception immediately from .autoPagingIterator if it is ever called without the global APIKey set or passing in RequestOptions to .autoPagingIterator – although this would be a breaking change.

Marking this as future and breaking-api-change, hope to put together a PR soon.