We're big users of both Slack + Screenhero at Thinkful for our students communicating with each other in real time (Slack) and pair programming with mentors (Screenhero). We were even spec'ing a feature to make Screenhero the only tool for mentor sessions. Congrats to the Screenhero team – you built a great product and deserve this, but it's sad we'll have to switch to another product. We can't wait months to have something available, and it's not clear the new features will do what we need :/
Yeah, congrats to both teams. I agree wholeheartedly with Dan's comment; I love each of your products separately and look forward to playing with the integration down the road, but I'm disappointed to lose the existing Screenhero now.
This is actually one of the very few things that has bothered me about Stripe – they don't make their volume pricing public (Amazon does, now Balanced does). We've had to email when we hit larger sums to get pricing reduced.
Edit: although to be fair, I asked them about this, and they said their processing costs vary user to user, so they don't have a simple matrix (rather, they apply discounts based on the costs associated with an account). That's probably the best possible answer short of a pricing matrix...
Right; we've gone back-and-forth on how best to implement our volume pricing. The upside of a clear pricing matrix is that it's clear. The downside is that it's conservative -- we can (and do) give lower pricing than what we could commit to in a matrix like this to many users.
Perhaps we should release a matrix of what we do on average (or a set of minimum discounts) or something.
(As ever, feel free to drop me a line to discuss -- patrick@stripe.com.)
we can (and do) give lower pricing than what we could commit to in a matrix like this to many users.
Can you elaborate on this? What factors influence what rates you can (and do) give? Chargeback rate? Mix of card types? Type of product or service being sold?
Perhaps we should release a matrix of what we do on average
I think that would be great -- even better if it's combined with a list of situations which would result in the rates being higher or lower than the norm.
The biggest factor in processor costs is actually the card mix, and not the volume that a business generates. To give you some sense, international, AmEx and corporate rewards cards tend to be much more expensive to process. Debit cards, on the other hand, tend to be fairly inexpensive to process for (although, despite the costs mentioned elsewhere in the thread, not all debit cards qualify for Durbin debit rates).
Balanced's pricing matrix only takes one factor (volume) into account. So, for example, if a business accepts a high percentage of debit cards, we can offer a significantly lower rate than the prices in Balanced's matrix.
Generally, we hold to the offered rate even in the case that the card mix changes and becomes more expensive. In the case that the card mix becomes less expensive, we'll decrease the rate as our costs have changed and we can offer a better price. Our pricing is always based on the costs of the transactions, rather than volume alone.
There are downsides to focusing rates and adjusting them on volume alone. With the Balanced pricing matrix, if a merchant has a mediocre Q3 in volume, their pricing could increase for the highest volume quarter (Q4), even if Balanced's effective cost per transaction hasn't changed at all.
> Generally, we hold to the offered rate even in the case that the card mix changes and becomes more expensive. In the case that the card mix becomes less expensive, we'll decrease the rate as our costs have changed and we can offer a better price. Our pricing is always based on the costs of the transactions, rather than volume alone.
This poses an interesting optimization problem. Given that model, a customer should email you at the beginning of every month asking you to (re)evaluate their rate given whatever period (trailing month? trailing 3 months?) you use to determine the card mix.
If the card mix has changed such that Stripe's cost has decreased, the customer would get a lower rate. If the card mix has not changed or has changed such that Stripe's cost has increased, the customer would maintain the same rate.
The above process could further be improved if the customer keeps track of their own card mix and only emails when favorable to do so. This could even be automated.
> There are downsides to focusing rates and adjusting them on volume alone. With the Balanced pricing matrix, if a merchant has a mediocre Q3 in volume, their pricing could increase for the highest volume quarter (Q4), even if Balanced's effective cost per transaction hasn't changed at all.
Yes. It's certainly not perfect. We used to have a tiered model where in each month the first $x was charged at some rate, the next $y would be charged at another rate, etc. It became difficult for customers to calculate their effective rate and project into the future. We'll continue try to improve based on the feedback we get from customers on our current model. Regardless, we'll publish any improvements in our pricing model and make it available to everyone.
I don't want to make this conversation about Balanced vs. Stripe. I asked my question because I was genuinely interested and wanted to see if there was something we could learn from each other. If you do have an internal formula, I encourage you to publish it. If the model is better than the one Balanced uses, it will allow us to learn and for everyone to improve. That is the nature of openness and what we're trying to accomplish.
That's assuming we're only looking at the card mix for a given month. Generally, we're looking at a trailing 3-month period -- and if a user wants to email us every three months to ask if we can lower their rates, we welcome them to do so.
We've certainly thought about how we can be more open with our pricing, as Patrick mentioned, and for customers that want details about why their rate is the way it is, we'll definitely dial-in to the details. We optimize for simplicity though, as we know that many of our users don't want to read an excel spreadsheet detailing the variety of charges we incur from card networks and other parties, which factor into their overall rate. Many of our users have chosen Stripe because we abstract away all the complexity involving pricing.
Why not give clients the benefit of a rolling 3-month rate automatically? That way you could help educate them (by showing them their own data back to them- scheme tier x volume) as to how merchant charges work.
To keep it simple, you could require a minimum volume to participate which may also help you get people to consolidate their merchant activity with you, similar to the way traditional tiering works.
We certainly could offer cost+ pricing. In fact, that's the status quo in most of the payments industry right now. But as cristinacordova from Stripe points out above:
"We optimize for simplicity though, as we know that many of our users don't want to read an excel spreadsheet detailing the variety of charges we incur from card networks and other parties, which factor into their overall rate. Many of our users have chosen Stripe because we abstract away all the complexity involving pricing."
Balanced chooses to offer blended, simple pricing for similar reasons.
That makes sense – the main thing that bothered me actually is that I didn't (and still don't) know when to ask for discounts. Even if you said discounts vary, but we'll look automatically look at what we can offer when you hit the following sums... that would be great.
We had the same issue with our banking partners. Their pricing schemes are very opaque and we didn't know when we should approach them. We, and you, have better things to do than polling a bank/payments provider asking for discounts. The not knowing is part of the problem.
True. But we just love the experience of getting emails from AWS telling us we're paying too much and what we can do to bring costs down. Balanced is striving toward that level of transparency and customer focus.
Ha, thanks. We did put the signup form at the end so it didn't put too much pressure on the signup. We'd love to check out other examples of how to do that well if you have any?
Do you still think everything in that post holds? Would be curious to read an update from two years later. A number of changes seem to be happening much faster than anyone was predicting (i.e. adoption of MOOC's, the pending adoption of online into traditional universities). I'm curious if that would have you changing any of your theses.
Unfortunately I think most of it still holds. The underlying psychology of the typical consumer hasn't changed. I think it will take a lot of liquidity to stick around long enough in this market to see the underlying market dynamics shift. This means you either raise a ton of money (at which point the returns don't make sense to anyone except the later stage investors), you run it as a non-profit where you can have a very long runway from grants, or you scale slowly but surely for the next decade before the market catches up. It will happen eventually but I think it will take more like 10 years, not the 4-6 that most VCs need to generate returns.
We're hiring a lead engineer to build the future of programming education at Thinkful (thinkful.com). We work with students looking to advance their careers, pairing each with a mentor and a group of peers to work with as they learn web development.
We use python and angular.js, but you don't need experience with both to succeed here. It's more important that you care about our students and their success.
Email me if you're interested: dan at thinkful dot com
