[HN Gopher] Why doesn't Stripe use Stripe Billing?
___________________________________________________________________
Why doesn't Stripe use Stripe Billing?
Author : swyx
Score : 245 points
Date : 2022-10-13 14:19 UTC (8 hours ago)
(HTM) web link (www.getlago.com)
(TXT) w3m dump (www.getlago.com)
| orliesaurus wrote:
| To the author of this blogpost: you're using the wrong product.
| You want to use Stripe Connect.
| edwinwee wrote:
| First off, yes, Stripe uses Stripe to bill our own customers. In
| fact, for our larger customers who have negotiated complex
| pricing plans, we're currently migrating much of our manual
| billing to a system that's inspired by Stripe Billing.
|
| Second, this article seems to miss the point of Stripe. It seems
| to want to build a platform, which is what Stripe Connect is
| designed for.
|
| For example, charging a percentage fee is just one line
| (https://stripe.com/docs/api/application_fees):
|
| ` $application_fee_percent = 5`
|
| Slack, Atlassian, and Notion have all built their B2B billing on
| top of Stripe. But we don't target just B2B or B2C ecommerce in
| case a business has multiple revenue streams (which many
| businesses are increasingly adding). In fact, we designed Billing
| so it can flex across any business model--per-seat, usage-based,
| tiered, or even graduated.
|
| This is the point of Stripe. A single stack that flexes with your
| business as it grows and pricing that's public.
| hklgny wrote:
| I would be shocked to learn you're using stripe billing and
| checkout sessions successfully internally - those products are
| so convoluted in how they overlap and don't as to be unusable.
| All but the most basic use cases are a nightmare to both
| implement and then track rev Rec on. So much so that you've got
| a whole new product dedicated to trying to figure it out. If
| that were the result of a dog-fooded product I'd be pretty sad
| to hear it.
| gamblor956 wrote:
| Agreed, at my company we have a fairly complex custom
| reconciliation process set up just to reconcile our stripe
| billings.
|
| In contrast, reconciling pretty much every other payment
| processor is relatively straightforward.
|
| Somewhere along the way Stripe went from being developer
| friendly to becoming more convoluted than Java.
| kurrik wrote:
| We're always working on making Checkout and Billing gel
| together better, and our Revenue Recognition product
| automates ASC606-compliant accrual revenue reporting
| including automatically recognizing data from Stripe Billing.
| Have you talked to us yet about your use-case? Could you
| email me at ark@stripe.com?
| hklgny wrote:
| I appreciate the offer. We are very much working closely
| with you on implementation and have from the start (over 6
| years spanning many of your products). I am very familiar
| with all of your offerings.
|
| The core of stripe is great, we're fans. But as you add any
| complexity you end up with a mess of various internal
| account balances to maintain. It forces you into gross
| things like bin packing refunds, complex internal transfer
| fail handling. Toss in the inconsistent handling across
| connect and man, you'd be better off just going back to
| basic charges and ignoring all the value adds.
| tiffanyh wrote:
| > First off, yes, Stripe uses Stripe to bill our own customers.
|
| This is confusing because you're implying that Stripe _Billing_
| is used internally but another employee clarifies and says it's
| not, it's simply another billing service was created that
| predates Stripe Billing.
|
| https://news.ycombinator.com/item?id=33193807
| edwinwee wrote:
| Sorry, to be clearer--we are moving away from the old billing
| service my colleague mentioned and to a new one. Our new
| system shares similarites with the Stripe Connect + Stripe
| Billing flow I mention above (specifically
| https://stripe.com/docs/api/usage_records).
| mi_lk wrote:
| no bad intention - I am not sure when was the turning point
| but you appearing on a Stripe thread now seems like a
| negative signal recently, for me at least
|
| It's of course your choice, jfyi
| blast wrote:
| You say it _shares similarities_ with Stripe Billing.
| Above, you say _inspired by Stripe Billing_.
| "Similarities" and "inspired" are weasly ways of saying
| that it is _not_ Stripe Billing.
|
| It used to be that Stripe could be relied on not to do this
| sort of corporate doubletalk. The OP asked a direct
| question and you've given a misleading PR answer.
|
| I'm sure you're a nice person just trying to do your job,
| but your inevitable PR posts to HN, within minutes of
| anything Stripe-related coming up, are hurting your cause.
| The Stripe of the past would never have spewed propaganda
| like "This is the point of Stripe. A single stack that
| flexes with your business as it grows and pricing that's
| public" into HN threads. It's embarrassing, and what it's
| telling us is that culturally you've lost your way.
|
| Maybe that's inevitable on your way to world domination,
| but if you guys can no longer communicate honestly or treat
| readers as intelligent, you'd be better off not posting
| here. I like Stripe, by the way. I know this is harsh but I
| would like it to be helpful.
| ath0 wrote:
| Several of the concerns revolve around the complexity of managing
| multiple IDs (product SKUs, prices, etc) for a single
| subscription - and the author reaches the conclusion that this is
| because it's optimized for "e-commerce and not B2B SaaS".
|
| While from the buyer's perspective, "single negotiated cost with
| overages" may appear simple - it's a single bill after all - on
| the accounting side for the company selling the product, I'd
| expect it's much more complicated; with potentially different tax
| rates for different products and complexity around producing an
| auditor-defensible determination for "cost of goods sold" and
| "marketing expense."
|
| So for at least some of these requests, I see Stripe's posture
| here as helpful - it's not "requesting a dollar figure", it's
| "creating a detailed enough accounting trail behind that bill to
| operate your business." Looking across the breadth of Stripe's
| products, I'd give them the benefit of the doubt here.
| atian wrote:
| See how your site looks like on mobile with content blockers
| turned on.
|
| For me the navigation bar doesn't collapse and covers the whole
| screen.
| jonas-w wrote:
| It loaded slow but apart from that it looks normal. I use
| firefox on android with ublock origin.
| AnhTho_FR wrote:
| Thanks! we're working on this, the point is: the problem
| occur for a small portion of visitors, and we're iterating to
| reproduce that. Thanks again for the feedback!
| weird-eye-issue wrote:
| It loaded so slow I couldn't even get there. Was just a white
| screen for several seconds. I'm in Thailand but still this
| shouldn't happen
| coding123 wrote:
| They tried and then got locked out.
| cpursley wrote:
| What I'm interesting in is a front end where the underlying
| payment provider can quickly be replaced when Stripe/PayPal etc
| cancel you (for any reason at all).
| bredren wrote:
| For a long time, Apple stores used mobile devices other than
| iPhone to process payments on the floor. Windows mobile, I think?
| kurrik wrote:
| (I work on Stripe Billing). This is a question we raise fairly
| regularly internally at Stripe. The real, prosaic answer is
| because when we started working on Stripe Billing in 2017, Stripe
| had already built an internal billing system to bill its own
| customers. Stripe was 7 years old at that point.
|
| At the time, we got lots of feedback from the folks who had built
| that system. Our goal was to build a flexible billing system for
| all kinds of companies at different sizes, but we were definitely
| focused on smaller (doing maybe $100k-$10M of ARR) SaaS companies
| to start. We've come a long way since then and now power billing
| for a number of large/public companies. Atlassian, Figma, Notion
| and Slack are either using or migrating onto Stripe Billing
| today.
|
| Stripe Billing is a powerful tool with a role to play in any
| company's revenue management system, including Stripe's. Newer
| Stripe products (such as Atlas) do build on top of Stripe Billing
| but we haven't gotten around to migrating our existing stack.
| That said, I do have a personal goal of taking on more internal
| billing responsibilities over time (e.g. I think we could easily
| use Stripe Invoices internally today, and it's mostly opportunity
| cost keeping us from actually doing so).
|
| I do want to say that the specific use case covered in the post
| is something we have thought about a lot. I think about it as a
| pipeline with stages for collecting high volumes of usage events,
| aggregating them, mapping them to rate cards based on usage, and
| then producing recurring bills, collecting payment, dunning,
| etc... The post claims we don't do a good job on the first two
| stages (collecting usage events and aggregating them) is perhaps
| missing that the style of percentage-based fees is a one-line
| addition to a Connect integration as my colleague edwinwee
| mentioned below. It is also possible to have a scalable usage
| event collection/aggregation pipeline integrated with Stripe
| Billing. You can read this AWS blog post
| https://aws.amazon.com/blogs/apn/building-a-third-party-saas...
| for information about how to build such a system according to our
| best practices.
|
| While I'm here, I'm always eager to hear feedback on Stripe
| Billing from folks who are using it. My email is ark@stripe.com.
| cutenewt wrote:
| Lago is really gunning for Stripe Billing.
|
| Is Lago barking up the wrong tree? Or is there really an
| untapped opportunity here?
| Rafsark wrote:
| I'm Raffi from Lago. Frankly, Stripe is a awesome company.
| They've built amazing products, including Stripe Payments
| (the blog post starts with this exact same statement). When
| it comes to billing, we do believe we are creating a better
| solution, especially for companies having complex billing
| (usage based, for instance). At least, we offer a new
| solution to prevent additional % fees on revenue, vendor
| lock-in and rigid billing solution by creating the tool we
| would have loved to use.
|
| We do not bark up the wrong tree, but try to give our point
| of view about the perfect billing system
| AnhTho_FR wrote:
| Hi! I work at Lago.
|
| Billing is still a huge nightmare for engineers, this is what
| we're going after ->
| https://news.ycombinator.com/item?id=31424450
|
| We've built and scaled it internally in a 5x Fintech Unicorn
| before joining YC, we would have loved to use an off the
| shelf solution, but none of them were a fit.
| theturtletalks wrote:
| If Lago builds a billing UI and API that can connect to
| Stripe Billing, Paddle, Authorize.net, PayPal, etc. then that
| is a huge opportunity.
| swyx wrote:
| why exactly? is this just some form of xkcd-style "there
| were too many APIs so i built a superAPI" line of thinking?
| or is there something more fundamental about this problem
| you are referring to
| AnhTho_FR wrote:
| Interested in the answer too! Maybe you meant being a
| 'metering x billing layer' that can easily connect to any
| PSP, unlike 'Stripe Billing' that is only usable with
| 'Stripe Payments'?). In that case, we'd connect to
| 'Stripe Payments' (not Stripe Billing), which we already
| do :) Genuinely looking forward to your thoughts!
| theturtletalks wrote:
| Stripe Billing is not fully internationally available so
| a lot of software companies are opting for Paddle. A
| super API would allow users to easily switch between
| billing platforms and avoid lock-in.
|
| The other reason is that Stripe Billing is stupidly good.
| So good in fact, that they could raise they rates from
| 0.5% to 1-1.5% and most people would pay up since
| migration would cause downtime and man-hours. I use
| Stripe Billing now, but could integrate with Lago once
| and easily switch between payment processors.
| joshpadnick wrote:
| (This is my second feature request on this thread; apologies
| for any noise.)
|
| Stripe Billing helpfully allows you to set the original
| subscription start date to a past date, _but only at
| subscription creation time._ If we could modify the
| subscription start date, then Stripe could be authoritative for
| when 100% of our subscriptions actually started.
| kurrik wrote:
| Thanks! I'm curious about your use case and specifics about
| how you're looking at start date and how often you'd expect
| to update it (i.e. is this a one-time cleanup or a regular
| thing?). I'd welcome an email with some details!
| rtanks wrote:
| This is great information. Thanks!
| AnhTho_FR wrote:
| Hey Ark, I work at Lago, thanks for the detailed answer!
| joshpadnick wrote:
| We use Stripe Billing and it's gone very well overall, but the
| biggest miss for us is that Stripe conflates "contract term"
| with "billing frequency." We sign up customers for annual
| contracts but bill them monthly, but Stripe Billing only
| understands the "bill monthly" part of that.
|
| Are there any plans for first-class contract term support
| coming?
| anamexis wrote:
| You could use subscription schedules to end the subscription
| after 12 months.
|
| https://stripe.com/docs/billing/subscriptions/subscription-s.
| ..
| joshpadnick wrote:
| Yep, tried that. But we want an auto-renewing contract of
| 12 months, and subscription terms require you to have an
| end date.
| jawr wrote:
| Shameless plug, but at www.salesbricks.com we separate
| out billing schedule and contract terms. We also handle
| complex deal structures, upgrades and renewals!
| kurrik wrote:
| Yes, this is definitely a use case we've been working on. If
| you'd be willing to email me any more details about how you
| need things to work at ark@stripe.com I'll make sure the
| feedback makes it to the people working on it.
| neosat wrote:
| Thanks for some internal insights. I think the original post
| wasn't making the point that such a use case is not _possible_
| to build but rather that the architecture and design choices of
| Stripe Billing are not optimized for these use cases and don 't
| make it easy.
| AlecSchueler wrote:
| I loved the answer but it's a good point to raise in return,
| what makes migration to internal billing so unappetising for
| the teams at Stripe?
| longboardcat wrote:
| Hopefully because there's an actual business to be
| building.
| AlecSchueler wrote:
| Yeah, that's what I figured too as I was asking that.
| Focus on the product first. In a way it's actually a plus
| point that they haven't migrated, as it shows they're
| clearly focused on building.
| kurrik wrote:
| I wouldn't say it's unappetizing for us. Even
| contemplating the possibility offers us insight about
| what companies the size and complexity of Stripe need to
| go through in order to migrate Billing systems. e.g. back
| of house processes for revenue reconciliation and
| recognition need to work across both systems, we need to
| support bulk migrations of data, both systems need to
| recognize the "canonical biller" for a customer so that
| you avoid double-billing issues, you need to backfill
| invoices and ensure no gaps in numbering, product teams
| need to update their integration and provisioning code
| and so on. My observation is that large companies can
| spend 10s-100s of engineers on the order of several
| quarters or years to do this kind of migration safely.
|
| We've made several internal and a few external changes
| over the years to help our users with these kinds of
| issues and in my estimation we've been getting closer to
| making the commitment, but as of right now we haven't
| done a stop-the-world effort to change systems
| internally.
| AnhTho_FR wrote:
| Hi neosat! I work at Lago and co-wrote the post, this was
| exactly our intention. Thanks for pointing that out :)
| neosat wrote:
| Hey AnhTho - the points in your post resonate, and y'all
| seem to be doing some exciting work at Lago - good luck!
| [deleted]
| Biganon wrote:
| So, same reason why Microsoft uses SAP instead of Microsoft
| Dynamics. They would use their own product if they were to
| start now, but migrating from SAP would cost them millions and
| take a lot of time.
| jmartens wrote:
| Never host your status page where you host your app, and never
| use your billing product to handle your own billing.
| zcombynator wrote:
| Interesting that one YC company publicly attacks another YC
| company. I thought there's at least some "family" vibes there,
| instead of bitching each other now.
| AnhTho_FR wrote:
| Hi! I work at Lago. As we wrote in the disclaimer of the
| article, we're just stating how our positioning is different,
| extract here:
|
| "We were told recently: "We love your 'Stripe hate' content".
| While it was intended as a compliment, 'Stripe hate' has never
| been our intention.
|
| We partner with Stripe Payments and love their products. Our
| own product is an alternative to Stripe Billing (and Chargebee,
| Recurly, etc.) but with a deep focus on B2B and product-led
| companies. We actually have common investors on our cap table
| (e.g. Y Combinator and others)."
| vasco wrote:
| As the old men say at the park, there comes a moment in every
| SaaS's life where you need to spend a year of a team's time just
| adding Zuora. They are dark days but hopefully life is better on
| the other side.
| zcombynator wrote:
| @paulg isn't it against YC guidelines to attack other YC
| companies?
| ekofish wrote:
| I work at an HR/Payroll company with a phenomenal app that we put
| our blood, sweat, and tears into every single day. And every
| single day I clock in with Oracle Time and Labor. There's a legal
| reason for this and we do it for compliance. I'm guessing Stripe
| is in the same boat with this product despite its flaws.
| tiffanyh wrote:
| Twilio is the same.
|
| They use Zoom & Slack internally, not their own video and chat
| offerings.
|
| Dogfooding is a good thing.
|
| You'd be surprised how few companies actually do it (which is
| terribly shocking).
| [deleted]
| umvi wrote:
| In the case of GP he is saying they want to dogfood their
| product but cannot due to legal reasons.
| juliansimioni wrote:
| Dogfooding can often be a good thing but not if your target
| customer is a very different type of business than your own.
|
| For example, Stripe is a _very_ large company but their
| product is geared mostly towards small and medium size
| businesses.
|
| It's very possible that in the process of making Stripe
| Billing work for Stripe, they'd make it work less well for
| their actual customers.
|
| It's the same reason why Intuit probably doesn't use
| QuickBooks to do their accounting.
| twstdzppr wrote:
| There's got to be a better term than "dogfooding"
| simianpirate wrote:
| A salesperson that I worked closely with like to use:
| "Drinking our own champagne." I liked it enough I started
| using it though the engineer in me tends to be fine with
| "dogfooding".
| nsxwolf wrote:
| "Use your own product" was too simple and direct.
| Dylan16807 wrote:
| "Using your/their own product" is six syllables.
| Dogfooding is half that.
|
| In the version without "ing", that's 5 versus 2
| syllables.
| hnlmorg wrote:
| I'm definitely in favour of dogfooding. But it's worth noting
| that there is still a positive flip side to using competitors
| products:
|
| + you get to keep up with their advances so you're not
| relying on your customers telling you about your competition
|
| + in the case of chat apps, if your infrastructure goes down
| you can still work as a team to coordinate the remediation
| bombcar wrote:
| It makes sense to me - if Twilio undergoes a massive outage,
| do you want them to be unable to communicate as they try to
| fix it? So they use Zoom and Slack.
| bnt wrote:
| Email? "Massive outage" for Twilio would bring down a lot
| of products, they would have to be back up in minutes.
| antihero wrote:
| Just have that stuff as a backup?
| bombcar wrote:
| That can also work - but backups that aren't used can
| atrophy - and market segments could mean that what
| "works" for the company isn't what the company is
| selling.
|
| It might be a goal to move everything internal (I believe
| Google is now using Google Apps internally, but they
| didn't for awhile, even after other businesses were).
| loriverkutya wrote:
| They could use staging. Or the solution they have in place
| in case they have a video conference system outage while
| they are fixing their own outage.
| duxup wrote:
| Dogfooding is a good thing.
|
| However, I find it can get tiresome / has potential
| compilations.
|
| Customer's can be terrible with incomplete, bad idea, and
| nonsensical requests. But sometimes internally you get the
| worst "Someone spilled some words into email that don't sense
| / no you don't actually want that / bro this is accounting
| software not Photoshop." situations that folks who are more
| familiar with the origination might make, but customer's
| might not make.
|
| It takes an extra level of internal discipline to deal with
| dogfooding side effects at times IMO. Still, a good idea none
| the less.
| Thaxll wrote:
| This sounds terrible, it shows a lack of confidence in your
| own product, imagine if Google internally would use Zoom...
|
| I can tell you that devs that use their own product deliver
| better quality.
| sjtgraham wrote:
| Then why does Google Meet suck?
| marcosdumay wrote:
| Well, optimally you would want to use both yours and your
| competitors' products.
| cachvico wrote:
| This is a good question. Does Google use Meet? Are they
| still subject to the frankly ridiculous max resolution of
| 720p?
| SaltySolomon wrote:
| I mean, it also creates a circular dependency, if you have
| an issue with your own product and trying to fix it then
| you can suddenly not communicate.
| mattnewton wrote:
| That's why SRE teams at companies I have been at always
| keep an IRC server hosted separately from all their other
| infra.
| grensley wrote:
| The Facebook outage last year being a great example of
| this. They lost basically all internal communications.
| dghlsakjg wrote:
| The sound quality and filtering on Zoom is noticeably
| better than on Meets.
|
| Perhaps you also need to use the product that your
| competitors use to understand what you need to beat.
| Thaxll wrote:
| For testing and strategy maybe not for day to day use.
| airstrike wrote:
| Maybe alternate between the leading product and your own
| so you can experience the same pain users do when they
| are forced to use the inferior choice after becoming
| accustomed to best-in-class.
| neurostimulant wrote:
| I'm sure Google Meets works flawlessly at Google's office
| (presumably a short hop away to their data centers via
| dedicated fiber optics link).
| lazide wrote:
| Google has invested heavily in sound management in their
| rooms, and issued noise cancelling headphones to everyone
| awhile back they got to take home. That might explain
| some things.
| throwaway5752 wrote:
| "Dogfooding is a good thing"
|
| That gets repeated a lot but I have observed the opposite
| when you have a diversified company dogfooding an internal
| product that isn't strategic in their portfolio, or is
| targeted at a market segment that the company doesn't belong
| to. I have seen companies hamstring themselves by using a
| product that isn't the best offering for them or a poor
| technical fit, only because it is their own offering. Also,
| in the worst case, companies become develop tunnel vision in
| the market, because they don't regularly use the competition.
|
| If you have a large, international software company targeting
| small to medium business customers in the US, dogfooding
| would be counterproductive. It would probably harm their
| strategic customer base by overcomplicating their product
| with features they don't need at the same time it slows the
| parent company down by using a product that's poor fit.
| ridgered4 wrote:
| Also if your product is adware, full of dark patterns or
| generally hot garbage it might be really frustrating to
| use!
| cpeterso wrote:
| Like the Twitter employee who bragged that Twitter
| employees can turn off ads in their personal accounts.
| pseudostem wrote:
| Fanboy Alert! (I may be biased).
|
| Not a company, but OpenBSD dogfoods exclusively. And they
| do deliver a good product.
| throwaway5752 wrote:
| OpenBSD sure does - also a fan - and dogfooding _can_ be
| a really good thing. But one has to approach it
| critically and sensibly.
| crazygringo wrote:
| Yup.
|
| The idea behind dogfooding is that you get more/better
| feedback and more internal pressure to fix problems.
|
| But the product team should already be getting feedback
| from a diverse set of customers. And if they're not, that's
| what needs to be fixed.
|
| Dogfooding can also result in overprioritizing only your
| own company's product needs, and at worst the ultra
| specific issues that one particularly vocal VP is having,
| to the detriment of the overall customer base. (I've seen
| it happen way too many times.)
|
| Companies should use the best tools for the job, not
| necessarily the ones they make themselves. If those are the
| same, then great. If not, then also great.
| throwayyy479087 wrote:
| Oscar is the same. They no longer offer Oscar insurance to
| their employees. It's a liability to mandate that your
| coworkers information is stored in Production and accessed by
| Client Services.
| thedangler wrote:
| What HR payroll ?
| reaperducer wrote:
| The company where I work disallows us from using our own
| product because it would be considered a conflict of interest.
| Some co-workers say it's a federal regulation, but I've never
| seen that anywhere in print, so I suspect it's just a workplace
| rumor/justification.
|
| I've had customers complain to my face that we tailor the
| products to our needs, and are surprised (and sometimes vocally
| disbelieve) that we don't use it, ourselves.
|
| In certain industries, dogfooding is considered bad, and
| sometimes illegal.
| willio58 wrote:
| Yeah most of the time I hear conflict of interest I don't
| believe it at this point. Conflict of whose interest? If you
| used your own product wouldn't you learn some issues that
| exist within it?
| randomdata wrote:
| _> If you used your own product wouldn't you learn some
| issues that exist within it?_
|
| Isn't that the worry? Say a bug in your timekeeping
| software underreported hours worked and that lead to
| workers not being paid their agreed upon rate. When it goes
| to court you now have to prove that you didn't maliciously
| introduce the bug to save on employment costs, whereas if
| it is a third-party providing the software it's their
| problem. "Conflict of interest" is ultimately just another
| way to say "I don't want to assume the liability when
| things go sour". Nobody cares about conflict of interest
| when things go right.
| marcosdumay wrote:
| >"Conflict of interest" is ultimately just another way to
| say "I don't want to assume the liability when things go
| sour".
|
| No, it's not.
|
| It's "malice is not a reasonable explanation for things
| going wrong". It only changes liability when it follows
| malice, what is much rarer than you seem to think.
|
| It is also a way to assure people that you won't do
| something bad.
| [deleted]
| duckmysick wrote:
| Can I see the files of an example case where something
| like that happened?
| randomdata wrote:
| If it happened then one would claim that they have a
| legal onus. Conflict of interest is speculative about an
| unforeseen future.
| duckmysick wrote:
| I'm not familiar with that definition. On the other hand,
| the Department of Defense explicitly says it happens "if
| the particular matter will have a direct and predictable
| effect on that interest". Predictable being "a real, as
| opposed to speculative possibility, that the matter will
| affect the financial interest".
|
| https://dodsoco.ogc.osd.mil/Conflicts-of-Interest/
| randomdata wrote:
| The topic is centred around off-hand remarks made by
| someone as to why they aren't doing something (such as
| using their own product) and how, as pointed out by
| willio58, "conflict of interest" is used where there is
| no actual demonstration of conflict of interest. We're
| not talking about military rigor, as interesting as that
| subject may also be.
|
| Again, "conflict of interest" is what people often say
| when they don't know if it will affect them, but don't
| want to take the risk. "Regulation requires it", as
| illustrated in the first comment, is what people say when
| caselaw actually demonstrates that they would be liable.
|
| The fun thing about language is that it is fluid and can
| take many forms.
| mattkrause wrote:
| Conflict of whose interests? You say the product is useful
| and other people should buy it, while you yourself use it
| seems pretty aligned.
|
| It cannot possibly be the case that Microsoft runs on Open
| Office and MacBooks.
| Turing_Machine wrote:
| For a long, long time Microsoft was using Unix sendmail for
| its own internal mail system, while touting Outlook for its
| customers.
|
| They only started eating their own dog food when people
| started making fun of them in public.
| slekker wrote:
| What's the legal reason?
| MichaelCollins wrote:
| If the system happened to break in a way that was opportune
| for the employer but ripped off the employee, it's better to
| point fingers at Oracle than your own company.
| Pet_Ant wrote:
| So limiting liability.
| marcosdumay wrote:
| Limiting the cases of conflict of interests.
| nulbyte wrote:
| Doesn't the company face the same risk with its clients?
| MichaelCollins wrote:
| The risk is the appearance that the company was
| deliberately ripping off employees. When the employer has
| created their own labor tracking software, it's easier
| for mistakes to look deliberate.
| connicpu wrote:
| It's easier to convince others that it was a genuine
| mistake when you didn't personally profit from the
| mistake
| culturestate wrote:
| Corporate liability to customers and corporate liability
| to employees are two _very_ different things.
| [deleted]
| Merad wrote:
| Maybe not a legal reason per se, but even if you have
| production data access appropriately locked down there will
| be some people who hold the keys to the kingdom. There's a
| lot more risk of people peeking at things they aren't
| supposed to when the data in question is about their own
| company, friends, coworkers.
| lostgame wrote:
| I'm working on the iOS/WatchOS app(s) for a major bank, and
| fortunately of course most of our staff uses it; too - because
| of course we bank with the bank we work for. (There's tangible
| benefits to a staff account, even those who have accounts
| elsewhere I'm willing to bet still do their primary banking
| with us.)
|
| I've actually had an instance or two over my four years there
| where I discovered a bug in our PROD/App Store version myself;
| simply from using the software enough.
|
| It's really unfortunate that this isn't the case for a lot of
| dev shops. Dogfooding is incredibly important to QA.
| alfl wrote:
| Their account got banned too many times :)
| AnhTho_FR wrote:
| Curious about which account you're mentioning?
| ItMayWorkTryIt wrote:
| 100 writes per second seems like a generous default rate limit.
| Presumably if my real traffic is above that I can ask Stripe for
| a higher limit
| rattray wrote:
| You can.
| scifibestfi wrote:
| Evidence of a recursion limit in the simulation?
| Traubenfuchs wrote:
| The only damning evidence we need is quantum physic gotchas +
| uncertainty principle + matter/wave dualism which happen
| because the simulator does not have enough precision,
| performance or memory to fully simulate the reality within it
| operates and needs to cut corners. But maybe this simulation IS
| reality and reality is simply limited in its precision,
| performance and storage.
| mananaysiempre wrote:
| To call the uncertainty principle a precision limitation on
| measurement is something of an oversimplification.
|
| Passing from the general physicist's uncertainty principle to
| a more restricted but still physically meaningful case, the
| Fourier-transform version of the uncertainty principle
| (requires no physics to derive and) states that the narrower
| and less smooth a spatial representation of something is, the
| wider and slower-decaying its frequency representation
| becomes. (Sharp and abrupt sounds have wide spectra, which is
| why they get mangled into the strange but recognizable
| bubbling in low-bitrate MP3s. The two-dimensional case of the
| same phenomenon is well demonstrated by the JPEG "ringing"
| around sharp edges, with the caveat that JPEG transforms
| every 16x16 block of pixels independently.) Physics comes in
| here only when you say that position and momentum (amplitude)
| distributions are Fourier transforms of each other.
|
| If a single sample or the average value is all you get, then
| yes, the width of the peak becomes the uncertainty of your
| measurement. If you can get many samples, though, then you
| absolutely can trace the shape of that peak. It's just that
| the instruments used at the dawn of quantum mechanics were
| not built that way.
|
| (What "particle-wave dualism" means, I think nobody really
| understands except maybe Bohr scholars; "dualism" was his
| personal German-philosophy-style all-encompassing idea that
| he was smitten with before he even started thinking about QM.
| It's a wave, period, it's just that high-frequency waves can
| look like particle propagation if you squint, as seen in
| optics and acoustics.)
| dzink wrote:
| If I were a regulator I would be suspicious if a company runs its
| own billing on its own billing software and then something goes
| wrong with the numbers. Keeps honest executives honest in a way.
| Also keeps outages and hacker attack vectors somewhat contained.
| paxys wrote:
| This isn't as much of a gotcha as they think it is. Amazon was
| using Oracle databases until like 2019, _13 years_ after the
| launch of AWS. Same with pretty much every large company that has
| a mature hand-crafted tech stack in place. Sometimes the costs
| and complexity of migration are simply not enough to justify
| switching, even if the target product is your own.
| traceroute66 wrote:
| Xero is the same and it really pisses me off.
|
| In Xero you've got something called a "Xero Network ID", which is
| an ID that you can give to other Xero users and they can link it
| to your contact record on their account, which means that
| invoices they raise are automatically posted in your Xero account
| without you having to lift a finger.
|
| Now, you would have thought that Xero would do the same for their
| subscription invoices (i.e. automatically post them to your Xero
| account).
|
| But no.....
|
| Instead they send you one by email which you then have to post
| manually onto your Xero account. And they do that every ...
| single ... month.
|
| If you ask them "why ?", you get an arrogant reply that along the
| lines of "we're too big to use Xero, so go away you silly little
| person".
|
| But that doesn't answer the question. Xero is their dogfood. So
| even if they use Sage or whatever internally, surely it is not
| _that_ difficult for them to build an integration so they can
| post their damn invoices to the customer 's accounts.
|
| Rant over. ;-)
| yeutterg wrote:
| Slightly off-topic, IMO Xero has really gone downhill. The
| Yodlee integrations with banks fail so often these days, it
| makes it hard to use the product at all. When you refresh a
| bank/credit card feed or log in for the xth time, you have no
| expected timeline as to when the feed will update or whether it
| will even work. There are multiple buttons to reset a feed, and
| they do different things.
|
| It's nearly impossible to just log in and reconcile all your
| accounts because you are always fighting with unconnected bank
| feeds. This degrades the core value prop of making it easy to
| stay atop of bookkeeping--now I always have some form of
| "accounting debt" these days.
|
| I got so frustrated that I am in the process of migrating my
| personal account to Tiller + Google Sheets, and I'm still
| looking for a solution for our small business account.
|
| I agree about the billing issues; I waste time figuring out
| where the invoices live in the product and manually posting
| them. Otherwise, the product would be fine if outdated, if it
| wasn't for the unreliability of Yodlee.
| wharfjumper wrote:
| What country are you in?
| traceroute66 wrote:
| > I'm still looking for a solution for our small business
| account.
|
| For a long time I resisted moving to Xero.
|
| Unfortunately my hand was forced because my existing solution
| (MYOB which was then bought by Mamut) stopped being Apple
| compatible through their own lazyness (they refused to update
| the software for 64-bit compatability).
|
| Apple had pre-announced the post-Catalina 64-bit requirement
| years in advance. Every other developer out there had made
| the change. But Mamut/MYOB ... nope, they sent out a long
| email one day basically making that absolutely clear they
| were not moving from 32-bit.
|
| Their answer was to offer a "cloud" version. I say "cloud"
| because what they offered was a remote desktop connection to
| a Mac running an old version of software on their side.
|
| So hence I was forced over to Xero. My accountant was
| pressuring me too, but Mamut/MYOB killing off their own
| product was the straw that broke the camels back.
|
| (I believe they _may_ have finally relented and brought out a
| 64-bit version subsequently, but by that time it was too
| late, I 'd moved already. And I had lost trust in their
| software support abilities anyway by then).
| ghiculescu wrote:
| It's really unclear what everyone at Xero does these days.
| Their main product development seems to be keeping up STP
| compliance, and trying to move add-ons onto their new App
| Store. I haven't seen an exciting new feature in a long time.
| (Their business development team, by contrast, seems pretty
| busy.)
| devmor wrote:
| This article comes at a welcome time for me. I've been building
| out a usage-based B2B product and have wracked my brain on how to
| properly implement billing (without having to pay large upfront
| fees or integrate a more complex gateway that I don't really
| need).
|
| I'd never heard of Lago before but I think I'll give it a try.
| AnhTho_FR wrote:
| Hi Devmor, I work at Lago. Happy to learn more and to support!
| My email: anhtho@getlago.com
| clintonb wrote:
| https://stripe.com/docs/billing/subscriptions/usage-based
| devmor wrote:
| I use Stripe for other products, and their usage-based
| billing is limited to specific scenarios that are not one-
| size fits all. This is in fact the entire subject of the post
| we are commenting on.
|
| Why would you assume I haven't evaluated Stripe's offering on
| a post that is specifically about the shortcomings of
| Stripe's offering.
| 0_____0 wrote:
| Whenever I hear about a US based payment processor, I feel
| compelled to mention UPI, India's Unified Payment Interface.
|
| Basically, with fairly modest investment, the Indian government
| put together a system to allow instant transactions between bank
| accounts. There are no transaction fees.
|
| We have so many companies (sometimes the same company with
| multiple faces - Paypal/Venmo, Stripe, Clover, Square, all of
| whom want a cut of transactions for the incredible service of
| making a number go up in one place and down in another place.
| Instead of fixing bank-to-bank transfers, we're stuck with ACH,
| which for some godforsaken reason takes days to clear.
|
| There's no technical reason why the US can't have a system like
| UPI. There's no reason why we MUST allow rent-seeking payment
| processors to take a cut when someone in Mumbai can make a peer
| or merchant transfer for free in seconds.
|
| UPI: https://en.wikipedia.org/wiki/Unified_Payments_Interface
| selimnairb wrote:
| Is this a example problem from an updated edition of "Godel,
| Escher, Bach"?
| yucky wrote:
| Stripe is large enough to need their own dedicated merchant
| account, why would they use a product designed for smaller
| businesses?
| dangus wrote:
| Seems very understandable to me that your customers' profile
| doesn't necessarily meet your customers' customers profile.
|
| If I sell a cash register app to indie businesses who sell
| trinkets at the art fair, that doesn't mean my solution meets my
| own needs for billing my millions of those business customers.
| rlewkov wrote:
| Maybe own dogfood doesn't taste so good ... maybe
| ceejayoz wrote:
| Stripe Billing came _after_ Stripe, by years, and it 's
| intended for a different purpose anyways. Stripe doesn't bill
| _me_ ; they take a cut of what I bill _my customers_. That 's a
| very different model than Stripe Billing is for.
| thiscatis wrote:
| It's called Stripe Billing, not Stripe MDR. What a pointless
| exercise but I guess someone wi have some takeaways from this,
| not sure which one though.
| [deleted]
| swyx wrote:
| what is MDR?
| scrollaway wrote:
| Merchant Discount Rate. Another (confusing) name for what you
| might know as "payment processing fee".
|
| https://www.investopedia.com/terms/m/merchant-discount-
| rate....
___________________________________________________________________
(page generated 2022-10-13 23:00 UTC)