It's not clear to me what you are envisioning here.
ActiveMerchant is a payment gateway abstraction layer, and in fact it already supports Stripe. It has two use cases: A) legacy gateways with shitty APIs and libraries (eg. Authorize.net) and B) theoretical portability between gateways. At my company we recently swapped out AM for the Braintree gem because the lowest-common denominator made it inferior for interfacing against Braintree, and the payment interface surface area in the app is small enough anyway that the theoretical advantage if we switch payment providers is negligible anyway.
Stripe if anything has a better API and ruby library than Braintree (Stripe uses a lot of Ruby internally is my understanding), so what's missing?
A higher-level gem that gives you plugin payments would necessarily start making assumptions and compromises that would quickly whittle down the number of ideally-served use cases, whereas the Stripe API as it stands now is at the granularity to fit the maximum number of use cases without being over-complicated. If you want to make something easier I think you veer into clumsy high-level components that is more akin to Drupal than Rails.
Sorry, what I described doesn't jibe with my comparison to ActiveMerchant as you pointed out. However it would still be badass to get a dropin solution for using Stripe in more complicated applications. And I know Stripe has a better API than alternatives but that doesn't mean it isn't still tricky.
I'm not sure I agree that a higher level gem would be of limited use or only of use to a few applications. I think it can definitely be done in a way that would have helped me big time in all three applications I've integrated with Stripe despite their unique needs.
ActiveMerchant is a payment gateway abstraction layer, and in fact it already supports Stripe. It has two use cases: A) legacy gateways with shitty APIs and libraries (eg. Authorize.net) and B) theoretical portability between gateways. At my company we recently swapped out AM for the Braintree gem because the lowest-common denominator made it inferior for interfacing against Braintree, and the payment interface surface area in the app is small enough anyway that the theoretical advantage if we switch payment providers is negligible anyway.
Stripe if anything has a better API and ruby library than Braintree (Stripe uses a lot of Ruby internally is my understanding), so what's missing?
A higher-level gem that gives you plugin payments would necessarily start making assumptions and compromises that would quickly whittle down the number of ideally-served use cases, whereas the Stripe API as it stands now is at the granularity to fit the maximum number of use cases without being over-complicated. If you want to make something easier I think you veer into clumsy high-level components that is more akin to Drupal than Rails.