Show HN: We built an open source, zero webhooks payment processor

📝 Discussion Summary (Click to expand)

The three most prevalent themes in the Hacker News discussion are:

1. The Overwhelming Complexity of Integrating Payments (Especially Webhooks)

Users frequently expressed frustration with the complexity of integrating payment processors, particularly grappling with the sheer volume and intricacies of webhook event types, which developers feel should be abstracted away.

Supporting Quotes:
- The complexity leads to incidental knowledge overload: "Having to figure out which of the 100s of Stripe event types we need to handle and which ones overlap was the most stressful part of adopting their system," noted by user "whiskey-one".
- The current integration paradigm is described as dangerous: "The existing integration paradigm for payments, at its worst, feels like a warehouse filled with footguns on the floor with the lights turned off," stated "agreeahmed".
- Complexity is increasing due to regulation: "I'd bet the typical payments integration has more complex requirements now than those from 10 years ago. That's what usually happens as a space becomes more important and, therefore, more regulated," according to "agreeahmed".

2. The Debate Over Developer Experience (DX) vs. Core Functionality

There is a significant tension between the stated goal of providing a vastly superior Developer Experience (DX) and the opinion that this focus overlooks the fundamental role of being a true payment processor (handling bank partnerships, risk, etc.).

Supporting Quotes:
- Skepticism that DX alone holds value: user "guessmyname" genuinely asked, "Who cares about developer experience? Genuinely asking, because I’m a developer too and I certainly don’t care. What we care about is solving the actual problem of payments with the downstream companies."
- The product being layered on top of an existing service (Stripe) drew criticism: user "baobabKoodaa" noted, "For those who are wondering, like me, what is this? Is this a new alternative to Stripe? The answer is: no. This is an added layer of abstraction on top of Stripe."
- The counterpoint that good DX is solving a real problem: User "poly2it" stated, "Stripe became dominant by improving developer experience, which cuts implementation costs."

3. Dependency on Stripe and Questions of Moat/Lock-in

Many commentators quickly identified that the new system is currently a wrapper around Stripe (using Stripe Connect), leading to scrutiny over the true value proposition, the risk of vendor lock-in, and whether the company could ever move "close to the metal" away from Stripe.

Supporting Quotes:
- Direct observation of the underlying platform: user "baobabKoodaa" confirmed, "This is built on top of Stripe."
- Concerns about the difficulty of decoupling: User "agreeahmed" admitted, "Currently we're using Stripe to process payments..." and explained that moving deeper into the rails is a "long journey."
- The risk structure of being layered: User "globalise83" warned, "I believe that means you are more or less setting yourself up as a payment facilitator, meaning you and your other merchants will be kicked off Stripe at any time if too many of your merchants misbehave."

🚀 Project Ideas

Webhook Event Deduplication & State Mapping Service (WEDS)

Summary

A service that ingests raw webhooks from various payment providers (initially Stripe) and normalizes/deduplicates them into a consistent, clean stream of state change events relevant to the application lifecycle (e.g., CUSTOMER_PAID, SUBSCRIPTION_PAUSED).
Core value proposition: Eliminates the need for developers to map, deduplicate, and maintain complex logic across hundreds of provider-specific webhook events, abstracting away incidental knowledge about the processor's lifecycle approach.

Details

Key	Value
Target Audience	Developers using multiple payment processors, or small teams overwhelmed by vendor-specific webhook complexity (e.g., needing to handle `charge.succeeded` AND `payment_intent.succeeded`).
Core Feature	Webhook ingestion, normalization, and state resolution engine that outputs simplified, actionable events via a clean API endpoint or local database sync.
Tech Stack	Go or Rust for high-throughput ingestion; PostgreSQL with transactional integrity for state resolution; Kafka/RabbitMQ for event queuing.
Difficulty	High
Monetization	Hobby

Notes

Why HN commenters would love it: Solves the explicit pain point: "How would you dedupe processing these events vs customer.subscription.created? Today, there's a lot of incidental knowledge about your payment processor's specific approach to webhook events that you need to know in order to integrate them."
Potential for discussion or practical utility: Can be positioned as essential middleware for any multi-processor payment orchestration layer, standardizing application state regardless of the underlying processor's quirks.

Opinionated Subscription & Entitlement Synchronization Tool (OSEST)

Summary

A server component/library that synchronizes your application's internal feature entitlements and usage meters directly from the billing engine's source of truth, minimizing API reads/latency reliance on the remote payment system.
Core value proposition: Addresses the "split brain" problem where application logic must constantly query the payment provider API for truth, instead providing strongly typed, locally queryable state derived from the normalized events.

Details

Key	Value
Target Audience	SaaS developers building complex feature gating, usage metering, or subscription management logic in React/modern frameworks who dislike constant cross-service API reads for feature checks.
Core Feature	Opinionated database schemas and server SDKs that allow developers to store normalized billing state (derived from WEDS) directly in their own database, making entitlements instantly accessible locally (`db.customer.can_access('feature_slug')`).
Tech Stack	TypeScript/Node.js (for initial React/JS ecosystem targeting); PostgreSQL/MySQL; framework-specific hooks (React/Svelte) that read from the local data store efficiently.
Difficulty	Medium
Monetization	Hobby

Notes

Why HN commenters would love it: Directly addresses the concern: "If you care about responsiveness, I'm not sure that's a good idea [to query their API for state]," and provides concrete solutions for deriving app behavior from billing state, solving the "15 server-client boundary hops."
Potential for discussion or practical utility: Sparks debate on whether billing state belongs in the application DB (the "source of truth" debate) but provides a path for developers who prioritize local read performance and minimal external polling.

Payment Processor Agnostic Integration Standard (PPAIS)

Summary

A specifications layer and set of reference libraries designed to formalize the common lifecycle interactions (checkout initiation, charge status polling, dispute handling initiation) across major payment gateways (Stripe, Braintree, Adyen).
Core value proposition: Acts as a true payment orchestrator interface standard, abstracting away provider-specific differences in high-friction areas like 3DS flows and lifecycle inquiry, aiming for "migration should be low friction."

Details

Key	Value
Target Audience	CTOs/Engineers migrating between processors or actively building payment orchestration layers ("If you're in Stripe jail or banned, start using paypal").
Core Feature	A modular abstraction layer capable of receiving a standardized request, translating it to the required provider API calls (including handling provider-specific authentication/flow redirects), and returning a standardized payload.
Tech Stack	Python/Java (for enterprise service compatibility); OpenAPI specification defining the core interface; reference SDK implementations for 2-3 major providers.
Difficulty	High
Monetization	Hobby

Notes

Why HN commenters would love it: Directly answers the call: "What if there was some standard API interface for payment processors? Basically AWS S3 API, but for payment processors."
Potential for discussion or practical utility: Though acknowledged as extremely hard due to differing feature sets, driving a community standard for the most common interactions (like subscription changes or 3DS handling) would be highly valuable industry infrastructure.