'Not writing a single line of code'... so the code cursor wrote doesn't count?
Show HN: We built an open source, zero webhooks payment processor
171–180 of 230 posts
Re: Show HN: We built an open source, zero webhooks payment processor
#172The reason webhooks are popular is because they are easy, reliable and they work. Now I might have to spin up a whole area of infrastructure I may not yet have to track eg usage, subscription tier, cancellations etc
Webhooks are absolutely the right tool for async / background jobs, or events driven domains. I’m not sure payments, and its flip side of entitlements, is best modeled as an events-driven domains. In a perfect world money would trade hands and you’d just see what that meant for the features or value your customers could access accordingly. This is what happens in other domains of online commerce like Shopify. Shopify…
> I’m not sure payments [..] is best modeled as an events-driven domains.
But payments are event-driven in reality. Credit card charges can be disputed, some transactions only succeed after a delay, or transactions or refunds you thought were successful turn out to actually have failed. Some payment methods are more susceptible than others, but even credit cards are affected by some of this.
The point is, stuff will happen to your payments without you initiating the change, and out of your control. Like, you know, events. Now you will need to become aware of them, and either you keep polling updates for a lot of your payments to catch the one that changed, or you have the information pushed to you.
Webhooks are great for that.
(Edited because a word was missing.)
Re: Show HN: We built an open source, zero webhooks payment processor
#173Earlier quoted context omitted.
Webhooks are absolutely the right tool for async / background jobs, or events driven domains. I’m not sure payments, and its flip side of entitlements, is best modeled as an events-driven domains. In a perfect world money would trade hands and you’d just see what that meant for the features or value your customers could access accordingly. This is what happens in other domains of online commerce like Shopify. Shopify…
Cards don't really need webhooks (unless you get into 3ds). Other payment types may need webhooks because they are fundamentally async.
3DS is a big deal in Europe, and card payments can be disputed. So I'd argue that credit cards are async, too, at least on some edges that can be expensive to ignore.
Re: Show HN: We built an open source, zero webhooks payment processor
#174Quick feedback from a Stripe and Braintree customer, who wrote their own subscription system so as not to use Stripe Billing. The things that caused me problems in the past:
* inflexible subscription system
* unreliable web component for gathering credit card information
* unreliable 3DSecure implementation
* incompetent support (these four are the main reasons why I switched from Braintree to Stripe)
* complex and untestable flows for non-mainstream payment types (e.g. SEPA direct debit, IDEAL, etc — Stripe makes you think they will just work, while you need to implement complex logic in your system to make them work)
* PCI compliance (Braintree hires SecureMetrics, they audit everyone even if you are below PCI thresholds, and the audits are idiotic; they complain about ssh version numbers on Ubuntu LTS systems which have all current security patches, etc)
* US-centric thinking about invoicing, which makes invoicing unusable (I issue invoices only after a successful payment, because I owe tax on all invoices including unpaid)
* lack of B2B subscription billing using proforma invoices
Things that would worry me looking towards the future if I were to switch a payment processor now:
* pricing (this matters in spite of what HN often says)
* lock-in (Stripe Billing was free, then 0.5% of revenue, then 1% of revenue, what's next?)
* reliability of 3DSecure, as problems here are extremely difficult to debug and easy to blame on "customer's bank"
You might note that this list contains mostly non-technical items.
But overall I'm very happy to see competition in this field. Payment processing is in a sad state and there are not nearly enough companies doing this.
Re: Show HN: We built an open source, zero webhooks payment processor
#175Quick feedback from a Stripe and Braintree customer, who wrote their own subscription system so as not to use Stripe Billing. The things that caused me problems in the past: * inflexible subscription system * unreliable web component for gathering credit card information * unreliable 3DSecure implementation * incompetent support (these four are the main reasons why I switched from Braintree to Stripe) * complex and u…
> US-centric thinking about invoicing, which makes invoicing unusable (I issue invoices only after a successful payment, because I owe tax on all invoices including unpaid)
This sounds strange. I don't think there's anything US-centric about considering an invoice to be a payment request — which makes issuing them after payment nonsensical.
Re: Show HN: We built an open source, zero webhooks payment processor
#176Earlier quoted context omitted.
That’s a great point. We started with React because that’s what we knew best and the community we were most embedded in. We have no dogmatic attachment to React. We hope to support Svelte and Vue soon. We’ll start on that once we feel that our data model and flow are sufficiently nailed down that we feel comfortable committing to porting our SDK to other frontend frameworks.
May I suggest web components? For all their warts, they are perfect for a use case like this. Even React, the IE of frameworks, supports them properly in v19.
amen
Re: Show HN: We built an open source, zero webhooks payment processor
#177Quick feedback from a Stripe and Braintree customer, who wrote their own subscription system so as not to use Stripe Billing. The things that caused me problems in the past: * inflexible subscription system * unreliable web component for gathering credit card information * unreliable 3DSecure implementation * incompetent support (these four are the main reasons why I switched from Braintree to Stripe) * complex and u…
> US-centric thinking about invoicing, which makes invoicing unusable (I issue invoices only after a successful payment, because I owe tax on all invoices including unpaid) This sounds strange. I don't think there's anything US-centric about considering an invoice to be a payment request — which makes issuing them after payment nonsensical.
That doesn't match what I see. Shops don't issue an invoice until the product ships, well after payment.
Re: Show HN: We built an open source, zero webhooks payment processor
#178Quick feedback from a Stripe and Braintree customer, who wrote their own subscription system so as not to use Stripe Billing. The things that caused me problems in the past: * inflexible subscription system * unreliable web component for gathering credit card information * unreliable 3DSecure implementation * incompetent support (these four are the main reasons why I switched from Braintree to Stripe) * complex and u…
> US-centric thinking about invoicing, which makes invoicing unusable (I issue invoices only after a successful payment, because I owe tax on all invoices including unpaid) This sounds strange. I don't think there's anything US-centric about considering an invoice to be a payment request — which makes issuing them after payment nonsensical.
> invoice to be a payment request — which makes issuing them after payment nonsensical
Most EU countries use an accrual-based VAT system, where taxes are owed on any invoice issued, paid or unpaid.
This makes issuing them before payment nonsensical, because you will end up paying taxes on invoices that will never be paid, thus ruining your business.
A proforma invoice exists specifically for the purposes of quoting and requesting payment.
Re: Show HN: We built an open source, zero webhooks payment processor
#179Congratulations on the beta launch, an impressive product we will consider integrating. As a relatively new developer, I'm curious why the dependancy on React? Was there no way to get the UI you wanted without implementing a framework like React? We are Svelte based, so it's frustrating for us to have to drag in React for libraries like this.
That’s a great point. We started with React because that’s what we knew best and the community we were most embedded in. We have no dogmatic attachment to React. We hope to support Svelte and Vue soon. We’ll start on that once we feel that our data model and flow are sufficiently nailed down that we feel comfortable committing to porting our SDK to other frontend frameworks.
You should look at using Preact (4kb alternative) and supply your frontend code as fully encapsulated with embedded preact. That way you client would only have to render your widget/app into an existing DOM element:
> customPreactRootRenderFunction(document.getElementById("outlet"))
Re: Show HN: We built an open source, zero webhooks payment processor
#180Congratulations on the beta launch, an impressive product we will consider integrating. As a relatively new developer, I'm curious why the dependancy on React? Was there no way to get the UI you wanted without implementing a framework like React? We are Svelte based, so it's frustrating for us to have to drag in React for libraries like this.
> We are Svelte based, so it's frustrating for us to have to drag in React for libraries like this
To be fair, chosing Svelte over React explicitly means that - if the React installed/userbase is 10-50x as big, you will be frustrated with this a lot. But in the end I don't get the frustration, in the end react is not a framework and you can render any component into a single HTML node that is part of your Svelte system. If the external library is encapsulated well, you shouldn't even notice that is react based.