The best observation from the article is that payment system complexities are not entirely technical. Some that we experience:
The ___domain is really complex - credit card transactions have many variables that can make endpoints unhappy, add internet payments to the mix (like PayPal) and you are in for a madhouse
External systems are full of surprises - you get an error response to your payment request, but then money suddenly appear on the merchant account. Or API changes without notice. Or test environment behavior is different from production. Or any other surprise that can come up from integrating to third party service.
Every transaction counts - you need to carefully consider which errors you ignore and move on, for which you try to cancel the transaction and which are just fatal failures.
Logging, logging, logging - having good information in logs is half the battle in disputes (which come up regardless of how fault tolerant your system is).
Your clients come from all walks of life - you don't have any guarantees about the user agents - IE8 support anyone? Odd mobile browsers? Paranoid browser settings? All of that can cause havoc in your presentation layer and cause endless mysteries.
I am not sure if Erlang (or any platform for that matter) could help with such issues. The key is having development team of technically competent people who care about the project. The rest is implementation details.
The hardest thing about building payments, by far, is getting users. The technology & operations are not too hard. Regulatory can be difficult if you're conservative.
The ___domain is really complex - credit card transactions have many variables that can make endpoints unhappy, add internet payments to the mix (like PayPal) and you are in for a madhouse
External systems are full of surprises - you get an error response to your payment request, but then money suddenly appear on the merchant account. Or API changes without notice. Or test environment behavior is different from production. Or any other surprise that can come up from integrating to third party service.
Every transaction counts - you need to carefully consider which errors you ignore and move on, for which you try to cancel the transaction and which are just fatal failures.
Logging, logging, logging - having good information in logs is half the battle in disputes (which come up regardless of how fault tolerant your system is).
Your clients come from all walks of life - you don't have any guarantees about the user agents - IE8 support anyone? Odd mobile browsers? Paranoid browser settings? All of that can cause havoc in your presentation layer and cause endless mysteries.
I am not sure if Erlang (or any platform for that matter) could help with such issues. The key is having development team of technically competent people who care about the project. The rest is implementation details.