Live data from Hacker News

SaaS We Happily Pay For

francescodilorenzo.com

161–170 of 229 posts

Re: SaaS We Happily Pay For

#162
post #147

Earlier quoted context omitted.

Last time I worked with (on?) a payment processor we got special credit cards that worked like Stripe's test numbers for testing production. I.e. some cards would go through, others would fail with errors specific to each card number. They were probably one of the most closely guarded pieces of equipment we had since the cards that cleared did so at any merchant so it'd work at point of sale but the vendor would neve…

I'm surprised the payment system is designed in such a way to make that possible

It's the way the credit system was designed, even before widespread computer networking - based entirely on trust. The customer would bring the card in and the merchant would make a signed carbon copy and call it in or deliver the receipts to the bank every day, which would settle the accounts between banks over a week or so, with the credit card provider carrying some level of liability. This is one of the reasons credit cards weren't accepted most places until networked POS terminals and instantaneous verification made the trust more practical.

Some merchants have their own verification steps in addition to the terminal like Best Buy checking a customer's ID to see if it matches the card and one of these special cards wouldn't fly if anyone actually looked it. It's not like you can walk into a Lamborghini dealership with one like you can with a Centurion card (which has some sort of concierge service for verifying large purchases IIRC).

Re: SaaS We Happily Pay For

#163
post #147

Earlier quoted context omitted.

Last time I worked with (on?) a payment processor we got special credit cards that worked like Stripe's test numbers for testing production. I.e. some cards would go through, others would fail with errors specific to each card number. They were probably one of the most closely guarded pieces of equipment we had since the cards that cleared did so at any merchant so it'd work at point of sale but the vendor would neve…

I'm surprised the payment system is designed in such a way to make that possible

It’s really easy to set this up. Authorizations for changes get routed to the bank of the issuer. It’s no different than rejecting for a bad a zip code, except it’s based purely off the card number.

Re: SaaS We Happily Pay For

#164
post #91
post #53

> We pay for this, even if we are the ones making it, to test our Stripe Integration. This is so important! This can go wrong even at large companies. At Netflix we once had a billing issue and it took a while to even notice, because no one in the company was paying for it (it was just free for everyone), but it looked like just general attrition, not people slowly having failed payments. After that incident, the com…

Actually technically this is prohibited by stripe. They explicitly ban testing your app in production. We have offered suggestions many times to them, but still no feature here.

Isn’t this like Amazon employees buying stuff from Amazon with their personal card?

Re: SaaS We Happily Pay For

#165
post #147

Earlier quoted context omitted.

I'm surprised the payment system is designed in such a way to make that possible

It's the way the credit system was designed, even before widespread computer networking - based entirely on trust. The customer would bring the card in and the merchant would make a signed carbon copy and call it in or deliver the receipts to the bank every day, which would settle the accounts between banks over a week or so, with the credit card provider carrying some level of liability. This is one of the reasons c…

Presumably, somewhere within the bowels of American Express, there's a test card for testing the Centurion large-payment verification process, where feeding it through a merchant and having them run a verification on it, will get them routed to a mock concierge on Amex's side (or rather, a human concierge diverted to follow a special mock workflow script.)

Re: SaaS We Happily Pay For

#166
post #52

If you go to that Linear one’s site on an iPhone and zoom in really fast on their image of the todo list client, it immediately restarts your phone.

Does the same on Chrome on an iPhone 8. Interesting.

Apple mandates WebKit as only allowed browser engine. If a page crashes iOS the error is likely in engine itself so it doesn't really matter what "browser" you actually use.

Re: SaaS We Happily Pay For

#167
post #103

Earlier quoted context omitted.

I've always heard that, for the US, when thinking about salary you want to about double what the employee makes when considering the employers cost.

This is overkill, add 35% to the top and you will be closer (depending on absence/sick levels). Statutory allowances in the UK are higher than in the US, and in the UK for instance you would add: - 12.5% national insurance + apprentice levy - 3-4% pension - 10% of days as holidays - 5% of days as sick / other leave (dependent on amount taken in reality) - 2% payroll fees / other Note, this excludes training and equip…

That metric isn't just about actual payroll expenses, but also things like office space, janitorial services, etc.

Re: SaaS We Happily Pay For

#168
post #13

Earlier quoted context omitted.

~$200/month for a 3 person startup might seem high. now calculate the cost of a server to host that FOSS stuff and the time and energy to maintain it, backups, etc. TBH i would rather put that time and energy in my startup instead of maintaining a FOSS stack for my company.

Do you think FOSS stacks are made of ice? That they would melt if you don't constantly resupply fresh ice from arctic excursions. Surely you maintain your start-up tech on F/OSS, as most of the internet does, so just use the person who types 'apt-get update && apt-get upgrade' on your service to do the same on your local VM. Or leave keep it local and literally never update it. It wont melt.

> Do you think FOSS stacks are made of ice? That they would melt if you don't constantly resupply fresh ice from arctic excursions.

Yes, if you care about things like not getting oWn3d and having your customer data exposed.

Re: SaaS We Happily Pay For

#169

Shhh... you can do almost all of this on Github private repos for free. Tasks and issue management, wiki, kanban board, discussions, ci/actions to trigger other stuff (send notification email for e.g.), storage of docs, revision control, tagging and organization, notebooks (with code too!), static hosting, support tickets, and so much more with Github API/webhooks :) Startup of this size shouldn't be spending a dime…

$100/mo won't make or break this startup. Inability to move fast might. Money of this scale is not a problem. Remember the insight from The Goal . Optimize at the bottleneck alone.

This sounds interesting! Where can I read more?

Re: SaaS We Happily Pay For

#170
post #53

> We pay for this, even if we are the ones making it, to test our Stripe Integration. This is so important! This can go wrong even at large companies. At Netflix we once had a billing issue and it took a while to even notice, because no one in the company was paying for it (it was just free for everyone), but it looked like just general attrition, not people slowly having failed payments. After that incident, the com…

My company does this too, for the same reason. (Not using Stripe though.)
Post reply on HN