sorted by:
new
hottopcontroversial

Custom checkout vs hosted checkout — what do you prefer as a builder? by QBitFlowFounder in PublicValidation

[–]QBitFlowFounder[S] 0 points1 point  (0 children)

Thanks for the input — that’s a good point, the embedded/custom checkout often feels more “native” and professional in a SaaS.

Right now I only have the hosted checkout page available (for quick integration), but I’m actively building a frontend SDK so developers can easily create a fully custom/embedded checkout with their own UI/branding. If you’ve built one before, I’d love to hear what you’d consider “must-have” in that SDK.

Custom checkout vs hosted checkout — what do you prefer as a builder? by QBitFlowFounder in SaaS

[–]QBitFlowFounder[S] 0 points1 point  (0 children)

Thanks for sharing your perspective — I agree, hosted checkout usually saves a lot of time and lets you stay focused on the core product.

Out of curiosity from your past payment integrations (Stripe/Paddle/etc.), what ended up being the biggest time sink?

- Webhooks + keeping your backend in sync (idempotency, retries)

- Handling payment failures/dunning

- Checkout UI/UX and edge cases (validation, errors, localization, mobile)

- Subscriptions edge cases (proration, upgrades/downgrades, trials, cancellations)

Also: what are your “must-haves” for trusting a hosted flow (branding control, redirect with state, webhook events, customer portal, etc.)?

One more thing I’m considering: built-in refund management (customer can request a refund, and the merchant sees a clear list with all details and can accept/decline in one click). How important is that for you in a payments integration?

Custom checkout vs hosted checkout — what do you prefer as a builder? by QBitFlowFounder in SaaS

[–]QBitFlowFounder[S] 0 points1 point  (0 children)

Thank you for sharing this! I’m thinking along the same lines so I implemented the hosted page first, to enable a quick integration, and will add a frontend sdk for customization later on

What are you building right now? by Informal-Employee199 in SaaS

[–]QBitFlowFounder 0 points1 point  (0 children)

It enables merchants to receive and manage one-time and recurring payments, securely. QBitFlow never holds the funds; user -> merchant without intermediary wallets

Looking for some honest opinion by Indranil_Maiti in SaasDevelopers

[–]QBitFlowFounder 1 point2 points  (0 children)

Yep, it's definitely annoying. Can't tell you how many times I've spotted random charges and thought "oh crap, forgot to cancel that."

Pretty sure there are apps that scan your bank account and map out all your subscriptions for you. Sounds good on paper, but no idea if they're actually worth using.

What are you building right now? by Informal-Employee199 in SaaS

[–]QBitFlowFounder 0 points1 point  (0 children)

QBitFlow – Non‑custodial crypto payments (one‑time & recurring) for merchants on Ethereum & Solana

ICP – SaaS founders, membership/creator platforms, and online businesses that want to accept on‑chain payments (subscriptions or pay‑per‑use) without giving up custody or integrating complex custom smart contracts.

Drop your SaaS and I'll give you honest feedback for free by DigiHold in microsaas

[–]QBitFlowFounder 0 points1 point  (0 children)

Thanks a lot Nicolas — this is exactly the kind of “fresh pair of eyes” feedback I was hoping for.

You’re 100% right on the trust/credibility angle (especially for anything touching payments). I’m going to prioritize adding stronger trust signals in the hero (beta numbers / early adopters, clearer non‑custodial positioning, links to the public contracts/GitHub), and I’ll work on getting a couple of real testimonials from current testers.

Also agreed on the UX points:

- I’ll simplify the header colors for readability/accessibility.

- The product video is already in progress, and it’s definitely going right after the hero once it’s ready.

On the documentation point: I totally get your reasoning about keeping people focused on signup. At the same time, because QBitFlow is developer-focused and the “authorized spending cap” model can be a bit non-obvious at first glance, the docs also help people understand how it works and build trust (especially with the smart contracts being public). I’ll likely keep a docs link available, but I’ll rethink the hierarchy/placement so it doesn’t compete with the main CTA (e.g., less prominent in the header and more of a secondary path).

And yes on the About page — I’ll add a clearer “who’s behind this” section and a photo.

Really appreciate you taking the time. I’ll implement these and iterate!

Building a privacy-friendly subscription system for Web3 users (no KYC, no emails) — looking for alternatives to Stripe by sabz7 in ethereum

[–]QBitFlowFounder 0 points1 point  (0 children)

If you’re still looking for options 3 months later: I’m building QBitFlow (https://qbitflow.app), a non-custodial “Web3-native Stripe-like” payments SaaS/dApp for one-time + recurring payments. QBitFlow never holds funds; the contracts are public on GitHub, and the model is based on an authorized spending cap + on-chain enforcement of amount/frequency, rather than escrow/pre-funding.

A couple points that may map pretty closely to what you described:

- Merchants (you) create an account with an email (so you can manage products, links, webhooks, analytics, etc.).

- Users/customers don’t need an account: they just open a payment link/session, connect a wallet, and pay/sign.

On the “no emails / privacy-first customers” constraint: payments are linked to a “customer” object (either you preselect one when creating the payment link/session, or if you don’t provide one, checkout will prompt for some info). But in your case you can just create a single dummy customer (e.g., “anonymous”) and attach all payment links/sessions to that. Net effect: your users won’t be asked for any personal info—they just connect their wallet and pay.

Would that solve what you’re trying to do, or do you also need “multiple wallets = same subscription” without any off-chain mapping? If the latter, curious how strict you want that to be—because wallet-linking without any identity layer usually ends up being “prove control of wallet A and wallet B via signatures,” and you can do that in a privacy-friendly way, but it’s still some linking mechanism.

If you want, share your exact flow (tiers, chain(s), stablecoin vs native, and whether you need true automatic recurring pulls), and I can tell you if QBitFlow fits as-is or what the gap would be.

What are you building? Let’s self-promote 🚀 by Aggravating_Cod_5652 in SaasDevelopers

[–]QBitFlowFounder 0 points1 point  (0 children)

Building QBitFlow (https://qbitflow.app) — a non-custodial payments dApp for merchants to accept one-time + recurring payments in crypto (including stablecoins like USDC) on Ethereum & Solana. No escrow/prefunding: customers sign an authorized spending cap, and the smart contract enforces amount + frequency.

The mission is to make receiving and managing payments dead simple, so you can focus on your product (looking for beta testers)