[HN Gopher] Lessons Learned from Payments Startups
___________________________________________________________________
Lessons Learned from Payments Startups
Author : ben_s
Score : 58 points
Date : 2024-02-07 07:52 UTC (1 days ago)
(HTM) web link (www.pgrs.net)
(TXT) w3m dump (www.pgrs.net)
| tommiegannert wrote:
| This is a nicely varied list of lessons.
|
| > Often, I will prefer the database to logging
|
| Just don't start writing exception logs to the database, and not
| tell anyone that you've created a flood gate that will make you
| run out of production data storage at the worst possible time.
| zeroxfe wrote:
| I wrote a [1] post-mortem when I shut down my payment startup a
| few years ago. The vast majority of our challenges were non-
| technical: navigating regulation, high legal costs, complex
| insurance requirements, etc. on an uneven playing field with
| competitors with much deeper pockets than even a well-funded
| startup.
|
| [1] https://www.linkedin.com/pulse/quid-sudo-shutdown-h-now-
| mohi...
| algo_trader wrote:
| Nice write up, and i hope you dont regret the journey
|
| I am surprised you didnt mention fraud - is it because micro-
| payments are not "fraud worthy" or because it is a manageable
| problem ?
| zeroxfe wrote:
| We designed our systems to be resistant to certain types of
| fraud, but never got successful enough to be a target. :-/
|
| But also, yes, micropayments are far less "fraud worthy" from
| an attackers perspective.
| potamic wrote:
| The payments platform you talk about is a piece of tech every
| financial company ends up building. What did you do with all
| that code after shutting down? Did you consider either selling
| or open sourcing it?
| umeshunni wrote:
| These are great lessons from an engineering perspective. From a
| product perspective, I've learned 3 hard lessons:
|
| 1. Fraudsters will find your product and abuse it before real
| users do. If you see a sudden spike in usage, it's probably
| fraud.
|
| 2. Real users are very emotional when it comes to their money,
| even if it's a "low volume transaction" like $20. Anything you
| build that introduces friction between them and their money will
| get your support team yelled at.
|
| 3. Regulators and banks are suspicious of you, for lessons they
| have learned from 100+ years of balancing lessons 1 & 2 above.
|
| Balancing 1, 2 & 3 is an art and the difference between building
| a successful product and failure.
|
| All the cute UI and funnel analysis you do breaks when it hits
| fraud, user emotions and regulation.
| user_7832 wrote:
| I'm curious, would you say using a third party to handle
| payments (stripe/paypal/shopify etc) would help avoid some of
| these issues? I'm not sure I understand point 2, especially if
| there's a "regular" checkout page by one of these companies.
| PeterisP wrote:
| It would help avoid these issues, but if you're a payments
| startup then you probably want to actually keep some control
| over your core business instead of just being a reseller
| intermediary for an actual payments company which holds your
| customer's money, has all the leverage over what features and
| policies "your" product will have and gets most of the
| profit.
| monknomo wrote:
| In some ways it makes it worse, because your users will not
| understand that you aren't screwing up their transaction,
| it's Paypal. They'll just yell at you
| threeseed wrote:
| None of this is unique to payments or the financial sector.
|
| And it is bizarre to me that you could run a payments system
| without high-availability or immutability at its core.
|
| Also putting logs in a database alongside your core data is such
| a bad idea. There are plenty of solid, proven systems for log
| management that allow you to correlate against other databases.
| And it avoids the issue of you wasting limited write I/O on a
| non-priority task.
| rrr_oh_man wrote:
| > And it avoids the issue of you wasting limited write I/O on a
| non-priority task.
|
| Is it really an issue, though, in most cases?
| pgr0ss wrote:
| Hi, I'm the author of the blog post.
|
| > And it is bizarre to me that you could run a payments system
| without high-availability or immutability at its core.
|
| I'm not sure what you're referring to here as my post didn't
| really go into these topics.
|
| > Also putting logs in a database alongside your core data is
| such a bad idea.
|
| I'm not suggesting putting all logs into the database. I'm
| suggesting that for a certain type of info (that is often
| logged), I find it more useful to put it in the database
| instead.
___________________________________________________________________
(page generated 2024-02-08 23:01 UTC)