I disagree with argument that any integration platform that requests your Stripe keys is a "ruse to harvest api secrets." At Pipedream, our Stripe integration requires the user to authenticate using their keys as well - https://pipedream.com/apps/stripe

Okay, Why can't you use the Stripe Connect[0] oauth api? It's generally considered bad practice to ask for and store passwords for other services.

[0] https://stripe.com/docs/connect

Stripe Connect & OAuth was something we thought about. It's definitely recognised as a more secure method and it's also low friction to integrate. The only drawback comes into play with marketplace and platform apps. The platform itself may already be using OAuth with their customer.

We could offer our customers both options and let them choose which one is best.

Stripe has dedicated application API keys for precisely this purpose. You are likely doing it wrong.

Not sure this is totally uncommon. Zapier asks for Stripe keys also afiak, or am I missing your point?

Oh, wow I didn't realize that. I'm a little surprised it's a common thing. Stripe's secret key is the "keys to kingdom" so to speak. This means someone with the key can get up to all kinds of funny stuff.

Stripe also says not to do it:

> Your API keys give you access to Stripe’s systems and a global financial network. That access is what card testers want to exploit, so it’s important to keep your keys safe and put safeguards around the functionality those keys provide to prevent fraud and other malicious activity.

https://stripe.com/docs/card-testing#stripe-mitigations

> Your secret API key can be used to make any API call on behalf of your account, such as creating charges or performing refunds. Treat your secret API key as you would any other password. Grant access only to those who need it. Ensure it is kept out of any version control system you may be using.

https://stripe.com/docs/keys#keeping-your-keys-safe

To me this sounds like an example of bad practice commonly implemented. Along the lines of the litany of open source projects who's install instructions involve CURLing a shell file into sh directly. It's bad practice, but so commonly implemented people mistake it for good/fine practice.

To be fair, sometimes you need bad practice to make things possible to do. Plaid takes your bank username and password to scrape pages because it’s the only choice to make the tech.

Flouting the rules is the basis for a lot of successful businesses.

A qualified absolutely. I love to build side projects, and generally the first iteration is very poorly built. If your goal is to put "ideas on paper" so to speak, then you're 100% right. This could even make it to early production if you're really in a pinch.

I think though that there's a point where you need to move past the bad practice and find, or create the right way to do what you're trying to do.

Except in this case Stripe provides a way for 3rd parties to access your Stripe account without giving the 3rd party your password.

Here's Zapier's docs on that:

https://zapier.com/help/doc/how-get-started-stripe

It looks like this documentation might predate Stripe's auto-generated API keys, which generates a separate API key for each successive app, and then you are able to identify the app and revoke only those keys:

https://stripe.com/docs/keys#safe-keys

WooCommerce, the popular E-Commerce plugin for WordPress also asks for Stripe keys.

They ought to at least understand that Stripe Connect and OAuth can be used rather than literally giving them your API keys.

Stripe Connect & OAuth was something we thought about. It's definitely recognised as a more secure method and it's also low friction to integrate.

The only drawback comes into play with marketplace and platform apps. The platform itself may already be using OAuth with their customer.

We could offer our customers both options and let them choose which one is best.