Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

We do relatively lower volume of higher value ACH transactions (ie, 20K/transaction).

What's interesting is strip invoicing is pretty uncompetitive here.

Fee for sending one invoice is $100/invoice. For every 100 invoices you are spending $10,000.

OUCH!!!

In other words, if someone was allowed to do an invoicing app in this marketplace it might do ok for a group out there. A target would be folks doing ACH payments (you need to cap per invoice including payment fees at $10 to be competitive here I think).

EDIT: Sorry, corrected to be $100/invoice from $500/invoice which is still much higher than we see elsewhere to send out an invoice.



They charge 0.5% per invoice for the higher tier, so for 20k that would be 100 bucks. Which is still excessive imo, but not 500 bucks.


Yes, this math seems more accurate. And for businesses sending _many_ high-dollar invoices, we have custom pricing. (Get in touch at https://stripe.com/contact/sales or email edwin@stripe.com.)


But would you allow invoicing app into your app store?


That's really my question - I think there's room for a $5 or $10 invoicing solution (ie, cap invoicing fee at $5 or so). Maybe somewhat simplified. I'd like custom domain as well of course.


Why is invoicing a percentage and not a flat fee? Does it cost more to transact it?


Pricing works best when aligning with value instead of costs. In general you should also try to align your pricing with value for better margins (especially if you are have a monopoly condition).

The rationale is that Stripe believe that a small percentage will align better with customer acceptance of pricing than a flat fee per invoice, which allows them to capture more dollars from the relationship.


I firmly believe that transaction fees (incl invoices, etc) should be fundamentally a constant flat fee. Whoever builds a competitor to Stripe will blow everyone away.

The cost of transaction is the same. Customers are being robbed in day light with % based transaction fees since the dawn of time.

This entire industry is begging for disruption.


Transaction costs are not the same price per transaction. The major costs for most transactions are the risks (credit, irr, fx etc) associated with it not the fixed costs of infrastructure.

Those costs go up with the value of the transaction.


Good points, this was my oversight/ignorance. Surely it is not 100% value-based costs?


No. And you can do pricing that’s flat if you are really good at risk management but note that means the price for smaller transactions begins to subsidize the big ones.

See Atlantic Monthly vs Wise for different pricing types in fx transactions as an example.


Until you want value-based fraud prevention layers like insurance. Keeping fixed fee would knock that out of alignment. But perhaps your point would be that should be some sort of opt-in higher SLA tier so the transaction layer fee is low but the insurance etc. add-on layers are variable.


Sorry - correct - $100/invoice - which is really way way above standard market for invoicing software.

There is an additional payments fee that applies.


Sorry, question by someone who is not part of the USA (not even Europe, if it's a common case in Europe too). Why would you have to pay to send an invoice? It isn't just a PDF? Is there an extra mechanism that I am missing?


When people say “invoicing” in this context they generally refer to both the PDF and the transfer of money per the details on that PDF. How that money is transferred will incur different costs.


Ah got it. So you can send the invoice for free but if they pay you then the fee will be deducted from that payment. Thank you very much!


That's actually not correct. Stripe invoicing charges 0.4 or 0.5% on top of the normal payment transaction fee (for either card payments or bank transfers). Essentially, you are paying a % fee for a nice PDF (plus some reconciliation/reporting etc)


Startup: (n) a weird entity that would risk $20/k customer because $100 invoice is too much.




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

Search: