Making Your Own Merchant Service Provider
Difficulty of Building a Payment Processor / PayFac
- Several comments stress that building a true payment processor or PayFac is brutally hard: fraud, regulation, card-network rules, PCI-DSS, and banking relationships are the main hurdles.
- Stripe’s success is attributed to years of prep, a very narrow initial product, early customers they personally knew (minimizing fraud), and weak incumbents.
- Even if Valve or Itch built PayFac capabilities, their upstream acquirers and card networks would still impose the same risk rules and content bans; control doesn’t move that far upstream.
- PCI-DSS alone can overwhelm tiny teams like Itch; Valve is big enough to handle it technically, but only if they truly want to shoulder that scope and audits.
Crypto as a Proposed Alternative
- Some see crypto (especially stablecoins) as a natural bypass for card networks and chargebacks, particularly for low-value, one-off game purchases.
- Others push back:
- Historical Steam Bitcoin experience is cited: high fraud rates via 0-conf double-spends and money-laundering concerns.
- Irreversibility, scams, and laundering (e.g., ransomware → games → resale) are seen as fundamental issues without strong regulation.
- Volatility and weak fiat on/off-ramps make it unattractive for mainstream commerce.
- There’s disagreement over how much of this is “solved in 2025” with faster chains and Lightning vs. basic incentive and compliance problems remaining.
Censorship, Risk, and Regulation
- Many comments frame the problem as moralistic or risk-averse intermediaries (banks, card schemes, processors) deciding which legal industries (especially NSFW) may transact.
- Examples: adult content creators, niche fetishes, “high-risk” geographies being blanket-banned, Patreon vs. OnlyFans, and porn-focused billing companies.
- Proposed fixes:
- Laws requiring “transaction neutrality” for lawful goods/services.
- Treat payment rails as essential infrastructure with mandated non-discrimination.
- Use state actors (e.g., postal services, central banks) for digital cash–like systems.
- Counterpoint: processors legitimately avoid segments with high fraud/chargebacks and reputational risk; forcing them to serve everything could socialize those costs onto everyone.
Public or Bank-Led Alternatives (Pix, UPI, etc.)
- Enthusiasm for central-bank or consortium systems (Pix in Brazil, UPI in India, Interac in Canada, Faster Payments/Swish/SEPA in Europe) as cheaper, more neutral rails than Visa/Mastercard.
- Others note these still rely on banks and can inherit the same “moralizing” behavior.
- Detailed debate on US vs. EU systems:
- US wires/ACH are expensive, slow, and risky (ACH pulls, limited reversals); credit cards persist because they bundle consumer protection, credit, and rewards.
- FedNow and Zelle are emerging but fragmented, and chargeback/consumer-protection models differ.
- In Europe, instant bank transfers are cheap or free, but not always suitable as a universal card replacement (delays, weak integration with online checkout, lack of protections).
Capitalism, Banks, and Rent-Seeking
- Some blame “capitalism” and card networks for rent extraction (2–3% fees, rewards funded by merchants, captured unbanked markets via Western Union/MoneyGram).
- Others argue banks are the real bottleneck, with incentives to protect interchange revenue and delay true instant/cheap alternatives.
- There’s general agreement that payment rails have become a powerful chokepoint for both economic access and de facto content regulation.
Anecdotes from the Trenches
- People who’ve built PayFacs or payment companies describe:
- Upstream processors unilaterally banning entire categories or regions (e.g., Puerto Rico).
- A diffusion-image site kicked off Stripe with large potential fines and moved to crypto, losing most revenue.
- “High-risk” in-person industries forced into creative workarounds: reverse ATMs, cash-to-crypto, barter.
- One long-time payments founder emphasizes that deep, continuous domain expertise and regulatory navigation matter more than the code itself.