Hacker News new | past | comments | ask | show | jobs | submit | more cristinacordova's comments login

We have a beta of ACH-in (instead of just ACH-out, which is public). You can email amber@stripe.com for access.


(I work at Stripe)

You can't currently accept payments with Stripe via wire, but you can accept payments via ACH-in (currently in beta: email amber@stripe.com for access) as well as debit/credit card. You could certainly do exactly what you describe with ACH-in and a separate authorization/capture process via credit/debit card, however authorizations expire in 7 days, so you may want to keep that in mind.

I suggest doing a separate authorization and capture via credit card (https://stripe.com/blog/auth-capture) OR accepting payments via ACH-in, rather than attempting to do both at the same time which can lead to customer confusion.

Stripe only charges upon a successful transaction (https://stripe.com/pricing), so the uncaptured authorizations will not cost you money.


Thanks!


(I work at Stripe)

That's not currently possible with our marketplace products (Connect or Transfers).


Stripe's now available in many more than four countries: https://stripe.com/global


The multi-currency capabilities (including the ability to charge in Naira) are only available to businesses based in Europe and the UK with banks in Europe and the UK. We do plan to bring Stripe to more countries, including Nigeria.


edit I wasn't able to edit the above comment, but I was referring to the US and Europe above, not the UK and Europe.


Stripe will immediately convert the currency to the user's local currency.


(I work at Stripe). No ETA yet, but we're actively working on it.


I was able to download it from the US App Store: https://itunes.apple.com/us/app/paper-stories-from-facebook/...


You may want to take a look at the some of the invoicing integrations built on top of Stripe: https://stripe.com/docs/integrations#invoicing


(I work at Stripe)

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.


What happens if a customer's card mix changes?


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.


zende, cristinacordova, I like where this is headed. Created an issue on Balanced's blog repo to discuss the topic further.

This would be a huge win for customers if we could find a way to work together to bring prices down even further!

https://github.com/balanced/balanced.github.com/issues/72


why couldn't you charge a markup based your cost? So I as a vendor pay more to process Amex and less for debit.

I can certainly steer my customers to use different cards by offering discount coupons for debit. On the internet 1% can mean a big swing in sales.


(I'm a Balanced employee)

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.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: