Ask HN: Would you use self-hosted payments to avoid payout holds?

Posted by alexmccain6 5 hours ago

Counter2Comment6OpenOriginal

No hold on payouts for online businesses.

I’m a founder and recently had a payout from a major payment platform delayed without much warning. The delay directly affected my ability to cover infrastructure costs, even though the money had already been earned. That experience was frustrating and made me question how much control builders really have over their own cash flow.

This got me thinking: instead of relying entirely on black-box gateways that pool funds and control payout timing, would builders want a self-hosted payments setup where money goes directly to their bank account using instant bank rails like UPI, SEPA Instant, or FPS? Not as a replacement for cards or Stripe, but as a way to avoid opaque payout holds where instant settlement is already possible.

Before building anything, I wanted to ask: is this something you’d personally use, or are payout delays simply an unavoidable cost of doing business online? I’d really appreciate hearing real experiences and honest opinions.

Comments

Comment by openspend 4 hours ago

Trying to solve it with OpenSpend. Feel free to steal the idea.

Sending e-transfers to businesses to pay for things is legal, unless I am mistaken. Please enlighten me.

Comment by alexmccain6 4 hours ago

That’s roughly the direction I’m thinking as well. Bank-to-bank transfers (e-transfers, ACH, SEPA, UPI, etc.) are already legal and widely used for paying businesses directly, without card networks or pooled balances.

The idea isn’t to change that, but to provide a self-hosted, non-custodial orchestration layer around those rails. The software wouldn’t hold funds or act as a counterparty....it would just help merchants initiate and observe transfers using their own bank relationships, with clear settlement and no payout abstraction.

Where things get tricky is cards, which are a very different model. But for bank rails, I agree the legal foundation already exists, and the question is more about how much orchestration you can provide before it’s considered intermediation.

Happy to be corrected if I’m missing something.

Comment by openspend 3 hours ago

I believe these companies are already doing it and charging a fee because they provide compliance and have required MSB licenses.

1. https://plaid.com/products/transfer/

2. https://www.flinks.com/products/pay

3. https://paytm.com/online-payments

OpenSpend should be open-source and free, unlike the companies mentioned above.

The idea is not only to provide the software but also legal templates like cancellation policy, refund policy, dispute resolution, etc., for different jurisdictions.

Comment by openspend 2 hours ago

For users/customers to make an effort to complete an online e-transfer, the incentive is to purchase the product or service with -2.9% + -$0.30 OFF or similar.

Comment by salawat 5 hours ago

Forget it. DoA due to Bank Secrecy Act, compliance costs (AML/KYC), money transmitter licensure, and the fundamental structure of the U.S. financial system

You could make a self-hostable solution, but the rest of the financial network would basically either refuse to accept your packets without sufficient proof of regulatory compliance in order to preserve their own good standing with regulators. It's a pretty jealously guarded sector, because it sorta has to be to make fiscal crime tractable.

I mean... Go for it if you want. Just be aware, your resulting impl cannot be legally employed without a money transmitter license.

Comment by alexmccain6 4 hours ago

That’s a fair point, and I agree with the core issue you’re raising. Anything that takes custody of funds or acts as an intermediary in the US quickly runs into BSA, AML/KYC, and money transmitter requirements, and those exist for good reasons.

The angle I’m exploring isn’t to bypass regulation, but whether a non-custodial, self-hosted orchestration layer can exist that never holds funds and only works on rails that already support direct settlement. The model is closer to paying a shop directly than paying through an intermediary....the software is never a counterparty, never pools funds, and the regulated entities remain the banks or processors on both ends.

In a US scenario, the idea would be that the merchant runs the software themselves, and onboarding doesn’t abstract compliance away but explicitly guides them through what they need in place to legally accept payments, linking out to the appropriate providers and only working once those are set up. My question is whether, in your view, that meaningfully changes the regulatory posture, or if simply being part of the payment initiation path still makes MSB treatment unavoidable.

Appreciate you calling this out....it’s exactly the constraint I’m trying to understand.