The title of the article is misleading, it's not programming that is the real issue, it's billing (the progamming issues are just a part in the article). Since the Credit Card companies & banks create lots of problems as soon as sex is involved (see FetLife's misadventures in HN previous articles for instance) in addition to the big chargebacks issue, and given that customers lie a lot (because they can), I think tha…
The problem is that most consumers don't plan ahead for wanting to buy a porn subscription. It's a spur of the moment decision. Any form of barrier you put in front of that decision -- whether it's extra verification, or a different digital currency they need to buy, or a prepaid card just for adult content -- drastically reduces the percentage of surfers that go from "guy looking at the site's preview page" to "guy…
The form says "To subscribe, remit $25 to account 12345678, and paste the transaction ID into this field." The merchant could then verify that the transaction ID matched up with a payment he received and complete the sale.
With a standardized microformat for the payment data, this could probably all be detectable and streamlined into browser plugins or apps-- you'd just see a button that redirects you to log into your bank's site with the transfer details prewired.
I figure this has plenty of benefits:
* The only remotely sensitive data you pass to the merchant is a transaction ID. You'd probably be able to actually do the sale without SSL, but certainly without most of the PCI compliance hassle.
* The merchant can't use the info you provided to enable an unexpected second charge or subscription.
* The bank can choose to make their process for executing the push transactions as "easy" or as "secure" as they (or the users) want. The merchant doesn't have to know, care, or worse, spend money to retool their site to support changes.
In a way, PayPal's flow is sort of push-oriented, but it's ugly in a lot of ways.