4 ms·

You're right. It would have been a lot better if we'd made explicit that we weren't intending to make a permanent commitment. This is good feedback for the next

by pc 6y ago

You're right. It would have been a lot better if we'd made explicit that we weren't intending to make a permanent commitment. This is good feedback for the next time we do something like this. (Our actual thinking was that we'd iterate on the product for a few years until we were confident it was good and worth paying for -- with both large and small companies using and paying for it -- and then revisit.)

porker 6y ago
> You're right. It would have been a lot better if we'd made explicit that we weren't intending to make a permanent commitment. And the original message, when I read it for the first time today, implies that it is for life because it's "beyond $1M" and there's no qualifier. I'm not using Subscriptions so I have nothing invested. But that's what your message says.
cabalos 6y ago
You're welcome; appreciate the response. For what its worth, I have yet to get an email about the increase and HN is the first I've heard of it. I should have known something was up when Stripe sent out the email survey two days ago about subscription pricing. Very strange that you only sat on those results for a day before pulling the trigger on this. Interestingly, some of the survey answers included concepts of a free tier. To me, the percentage makes little sense. You could be running 1,000,000 $10/mo subs, or 1,000 $1,000/mo subs and the cost is the same. This pricing model hits high value subscription companies significantly harder, even though Stripe's costs are lower.
- pc 6y ago
  > To me, the percentage makes little sense. You could be running 1,000,000 $10/mo subs, or 1,000 $1,000/mo subs and the cost is the same. This pricing model hits high value subscription companies significantly harder, even though Stripe's costs are lower. While this is true on some level, the challenge is that we'd have to set pricing at an inefficient point (i.e. we'd end up charging more than some businesses can afford to pay and less than others are willing to pay). If we charged $1/sub/mo (say), $5/mo subscriptions would be prohibitively expensive. At the other extreme, if we charged $0.02/sub/mo per month, it just wouldn't make sense to invest as much in improving the product, which would indirectly hurt businesses by depriving them of a counterfactual product that they'd like to be able to buy. Pricing is obviously always an exercise in trying to find a reasonable trade-off between simplicity / optimality and this is our best effort.
  - cabalos 6y ago
    You're right; regardless of which model you pick, one side is going to be affected more. I'm sure you ran the math on it and saw Stripe customers skewed closer to the $10/mo sub than the $1,000/mo sub. In the survey, there were a lot of options for dual pricing models. It must have been something you were considering. I'd be curious to hear why this was decided against? To be honest, none of the new Billing features are relevant to us. We'd much rather have new features gated, like customer portal is, than paying 0.5% for features we never intend to use.
    - pc 6y ago
      > In the survey, there were a lot of options for dual pricing models. It must have been something you were considering. I'd be curious to hear why this was decided against? I'm actually not sure. I'll check with the team. (The timing of the survey was coincidental, though -- we've been working on making our Billing pricing consistent since the start of the year.) > To be honest, none of the new Billing features are relevant to us. We'd much rather have new features gated, like customer portal is, than paying 0.5% for features we never intend to use. We seriously considered that. It gets pretty complicated (and error prone), though, with the number of different code paths that have to be maintained. The fact that such a large fraction of customers we reached out to directly were willing to pay for a more full-featured Billing (mostly on the basis of competitors being significantly more expensive) made us eventually conclude that it wasn't worth the complexity of having two adjacent versions of the product.
      - robertlagrant 6y ago
        > It gets pretty complicated (and error prone), though, with the number of different code paths that have to be maintained. This seems a little unlikely. Unless the billing side of things was too complex? :)
      - Dylan16807 6y ago
        Are the code paths really that complicated? If you want it extra simple, code path wise, then on accounts where it's not enabled you could hide the menu/API options for the new stuff and monitor your logs for anything sneaking through. Your actual payment processing backend doesn't even need to know there's a difference in feature set between these customers!
deleted 6y ago
[deleted]
Aeolun 6y ago
I’m more inclined to say that you’re deliberately going back on your words. Once you tell someone they can continue using it as is forever, you cannot later say ‘actually, we meant just a few years’.
posguy 6y ago
If current Stripe customers wish to switch to another processor like Vantiv, First Data, Chase Paymentech, etc will Stripe enable data migration from your ISO to another ISO? I did this when moving from a First Data ISO to Vantiv to ensure we could avoid collecting card data from clients again.

by pc 6y ago

porker 6y ago

> You're right. It would have been a lot better if we'd made explicit that we weren't intending to make a permanent commitment. And the original message, when I read it for the first time today, implies that it is for life because it's "beyond $1M" and there's no qualifier. I'm not using Subscriptions so I have nothing invested. But that's what your message says.

cabalos 6y ago

You're welcome; appreciate the response. For what its worth, I have yet to get an email about the increase and HN is the first I've heard of it. I should have known something was up when Stripe sent out the email survey two days ago about subscription pricing. Very strange that you only sat on those results for a day before pulling the trigger on this. Interestingly, some of the survey answers included concepts of a free tier. To me, the percentage makes little sense. You could be running 1,000,000 $10/mo subs, or 1,000 $1,000/mo subs and the cost is the same. This pricing model hits high value subscription companies significantly harder, even though Stripe's costs are lower.

pc 6y ago
> To me, the percentage makes little sense. You could be running 1,000,000 $10/mo subs, or 1,000 $1,000/mo subs and the cost is the same. This pricing model hits high value subscription companies significantly harder, even though Stripe's costs are lower. While this is true on some level, the challenge is that we'd have to set pricing at an inefficient point (i.e. we'd end up charging more than some businesses can afford to pay and less than others are willing to pay). If we charged $1/sub/mo (say), $5/mo subscriptions would be prohibitively expensive. At the other extreme, if we charged $0.02/sub/mo per month, it just wouldn't make sense to invest as much in improving the product, which would indirectly hurt businesses by depriving them of a counterfactual product that they'd like to be able to buy. Pricing is obviously always an exercise in trying to find a reasonable trade-off between simplicity / optimality and this is our best effort.
- cabalos 6y ago
  You're right; regardless of which model you pick, one side is going to be affected more. I'm sure you ran the math on it and saw Stripe customers skewed closer to the $10/mo sub than the $1,000/mo sub. In the survey, there were a lot of options for dual pricing models. It must have been something you were considering. I'd be curious to hear why this was decided against? To be honest, none of the new Billing features are relevant to us. We'd much rather have new features gated, like customer portal is, than paying 0.5% for features we never intend to use.
  - pc 6y ago
    > In the survey, there were a lot of options for dual pricing models. It must have been something you were considering. I'd be curious to hear why this was decided against? I'm actually not sure. I'll check with the team. (The timing of the survey was coincidental, though -- we've been working on making our Billing pricing consistent since the start of the year.) > To be honest, none of the new Billing features are relevant to us. We'd much rather have new features gated, like customer portal is, than paying 0.5% for features we never intend to use. We seriously considered that. It gets pretty complicated (and error prone), though, with the number of different code paths that have to be maintained. The fact that such a large fraction of customers we reached out to directly were willing to pay for a more full-featured Billing (mostly on the basis of competitors being significantly more expensive) made us eventually conclude that it wasn't worth the complexity of having two adjacent versions of the product.
    - robertlagrant 6y ago
      > It gets pretty complicated (and error prone), though, with the number of different code paths that have to be maintained. This seems a little unlikely. Unless the billing side of things was too complex? :)
    - Dylan16807 6y ago
      Are the code paths really that complicated? If you want it extra simple, code path wise, then on accounts where it's not enabled you could hide the menu/API options for the new stuff and monitor your logs for anything sneaking through. Your actual payment processing backend doesn't even need to know there's a difference in feature set between these customers!

deleted 6y ago

[deleted]

Aeolun 6y ago

I’m more inclined to say that you’re deliberately going back on your words. Once you tell someone they can continue using it as is forever, you cannot later say ‘actually, we meant just a few years’.

posguy 6y ago

If current Stripe customers wish to switch to another processor like Vantiv, First Data, Chase Paymentech, etc will Stripe enable data migration from your ISO to another ISO? I did this when moving from a First Data ISO to Vantiv to ensure we could avoid collecting card data from clients again.