(I'm a developer at Stripe who helps maintain our language bindings.)

+1. The original system was designed to be as flexible as possible and had the advantage of being able to support many different integrations that were straddling many different versions of the Stripe API, and all from within a single version of the Java library.

Its major downside of course is that the same flexibility somewhat compromises the developer experience, and the choice hasn't mapped well onto languages like Java where the expectation is that most functionality should be discoverable by the type system.

If it's any consolation, we're certainly aware of the problem and have a rough plan/roadmap on how to address some of the more appalling blemishes in usability.

I used Stripe's Java API for my website. I wouldn't say it was awful - it got the job done, and exception handling was well thought out. But it wasn't idiomatic Java. It felt like it had been put together by someone who knew a language other than Java really well.

Have you tried PayPal? Stripe's Java library may be a bit simplistic but at least the fundamental API concepts are sound.