Show HN: A low-code alternative for Stripe/Twilio Integrations
appstitch.dev
appstitch.dev
A couple of dashboard screenshots:
Stripe key collection:
https://i.imgur.com/q6evqlT.png
Plan Upgrade:
https://i.imgur.com/nwBZ2wL.png
EDIT: In the case of Stripe keys, I wonder if it's a strategy to bypass Stripe's "carding" detection? It seems like spreading out test transactions across multiple stripe accounts would make detection more difficult.
We could offer our customers both options and let them choose which one is best.
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.
Flouting the rules is the basis for a lot of successful businesses.
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.
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:
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.
Kinda the same deal on Stripe - if someone can guess / find out customer identifiers, which is a lot more likely when you're shipping them to frontends to use with your library (XSS...), they can create charges on your behalf? That's definitely a big risk fanout
We handle security in a few ways;
- Clients are initialised with Key & ID - We advocate for keys to not be hardcoded
- The key is used for request encryption and are never sent to the server. Request hashes are also used to make sure Man In the Middle Attacks are avoided
- Custom Auth Tokens can be sent with requests - On the server side we use your provided auth callback to ensure it is valid
What do you think about the steps we take? Tokens are really important because they offer another layer of protection
They're public facing (used by clients), so it doesn't really matter if they're hardcoded or not. I can rip them out of the dom/api calls/whatever.
For the second part, https covers you alone.
Auth tokens may start to pick at the puzzle, but at that point it's not obvious what I'm gaining if I have to bake custom authorization and authentication somewhere in any case?
You have a tough battle here - the security risk is huge. I don't personally see a value add yet, especially with Twilio/Stripe who have some of the lowest cost integration in the industry.
Not impossible to succeed in the arena, but the level of abstraction doesn't feel like the right fit yet
We want to help new startups, who are both looking to get their MVP build faster and are looking for no code/ low code options.
It will take time to build out a product for the larger community but for now we are looking to small a problem.
Thanks for your feedback
Its similar in principal, but it also creates a signed version of the stripe response [1], so you can hand it off to a backend and validate it without an additional stripe call.
Instead of requiring users to input auth keys, it uses stripe connect [2] to securely authenticate and act on behalf of users.
Using Stripe Connect is something we are going to add.
I saw the need when I had a couple of simple apps where I didn't really have a web server where I could create payments/subscriptions via stripe's server-side libraries. I also didn't want to use stripe's Checkout. I had to spin up a simple service just to confirm the payments and I figured I could abstract it.
The signed jwt response can be helpful because now you just need paysly on the frontend and your backend can be dependency free - all it needs to do is parse the token.
After reading the comments here, I realized that I was not. DO NOT USE THIS! This is a terrible product, and the entire concept should not exist. You're giving the keys to your Stripe and Twilio accounts away to some random third-party for... what, exactly? A slightly simpler development experience?
The fact that they don't mention that on main page makes me wonder if they even know what it is.
Use extreme caution.
Yep, same feeling here.
And there are even more red flags. - no information about what company/which individual is responsible for the service (I always want to know who I'm doing business with) - no contact information (no, Twitter is not a business channel) - no information about anything even related to liability and/or applicable laws - no ToS - no privacy policy (so no customers from the EU + possible lawsuits in the EU for the person who runs it) - no cookie policy, but still a cookie. Even better, it's valid for 10 years... (and here we go again with possible lawsuits in the EU)
Maybe there is some information about this after the registration, but it is: a) too late b) not how a serious company should communicate with potential customers/partners.
I'll pass.
Not if you handle the card numbers outside of Stripe (through a backend) instead of letting them pass through Stripe's iframe.
It's unclear to me if that's happening here. Stripe CAN work that way, but then PCI compliance is entirely on you (and you might as well get a regular merchant account at that point, since you've already gone to all that effort.)
Anything that touches cardholder data has to be PCI compliant. Stripe offloads PCI compliance for you because Stripe's front-end library lets the card number (etc) pass from your browser directly to Stripe's PCI-compliant backend, without ever passing through your application servers.
If you interrupt or proxy that flow, you become responsible for PCI compliance.
(Note that I have no idea if that's what they're doing here, but they could and you wouldn't even know until your account was closed for fraud. Also, this sort of centralized architecture can easily become a target for attack.)
I assume you would have to put in your secret key or give full access to the Stripe account? Both of which sound like giant red flags.
Also what exactly is a request? And pricing, how does $5 for 250 make sense? $5 to send 250 text messages?
Startups would put in their restricted key - a secret key with only the access that is necessary.
In terms of pricing, a request is an api call. I can see your point with $5 to send 250 text messages. It does sound steep. The first 5000 requests are at $20 which should adequate for most startups. Majority of our customers don't use more than 750 right now.
If we find customers maxing out the limits too quickly we will definitely adjust our pricing
> Apart from a few exceptions, this library mirror Stripe's API. You can use Stripe's Docs or our JSDocs for reference.
https://docs.appstitch.dev/stripe
Also, what does this cost? Is this a business or an open source library?
How does this compare to things like Chargebee or Recurly?
And, most importantly, why are you storing Stripe secret keys? If you are simply doing a better front-end/Stripe Checkout sort of front-end, why not just use the Stripe public key or even a regular Stripe Connect / API key if you need to do private API calls?
My stomach hurts.
Regardless of your political leanings, cancellation is an action, not a neutral position.