Show HN: PuBilling – Embeddable billing portal for your SaaS app | Hacker News Reader

Show HN: PuBilling – Embeddable billing portal for your SaaS app

pubilling.io

59 pointsraphaelcosta52 comments

Looks pretty cool.

Heads up though. There's a bug on your sample page: https://www.pubilling.io/sample

When you click the "Edit" button for the CC, the UI shrinks into nothing...

Thanks! Which browser are you using?

It's happening for me on Chrome Version 70.0.3538.110 (Official Build) (64-bit), for what it's worth. Seems like the Edit Window / Modal / Popup has some sort of resize mechanism to it or tied to it and it repeats shrinking the width of some container on a loop but there's nothing to tell that loop when to stop / what minimum width the loop / shrinking should end at.

Thanks, trying to reproduce here.

For sure.

Google Chrome Version 71.0.3578.98 (Official Build) (64-bit)

Thanks, trying to reproduce here.

I was not able to reproduce, but I changed some resize code, could you please check if it's still happening? Thanks!

We identified the issue and fixed! Thanks again!

It's also happening on Firefox 64.

And Firefox 63 on Mac.

It's quite hilarious actually because it starts squeezing everything to the left then it literally just poofs out of existence leaving just the "X" of the close button behind.

Here's a quick video of it in Firefox 63 on Mac:

https://gfycat.com/EssentialUglyHarborporpoise

We identified the issue and fixed! Thanks!

Really cool concept, thanks for sharing. :)

Small nitpick, but there's an extra l at the end of "renewal" in the mockup. The capitalization of "Next Subscription renewall" is also a bit off-- maybe consider "Renews on:" or "Next renewal"?

On the pricing side, I definitely agree with runako. Prices are much easier to lower than raise, and so you should experiment early on with the higher end.

Thanks for the feedback! I will fix those typos.

2 alternatives who tie pricing to revenues:

https://www.servicebot.io/pricing

https://www.chargebee.com/pricing

this one is free: https://www.chargebee.com/open-source-customer-portal/

Solid idea, after having built N billing portals in the past, I really like the idea of being able to drop in a billing portal.

That said -- raise your prices. You might try something that's more explicitly tied to revenue. But if not, I would try the 3 tiers at 39/99/199 (or 49/199/299). Maybe make a 0-10 customer tier that's lower cost. The bigger customers will demand more features to justify the price point, but many of those features will likely prove relatively easy to implement (SSO, 2FA, let them pay you via PO).

Thanks, @runako! Thanks for your feedback regarding pricing, get tied to revenue could be a great pricing strategy. We got featured on ProductHunt today, would be very nice to have your feedback there also.

I think if you tie to revenue, be sure to create a cap. Because if your price is going to go up and up forever for something that everyone knows is mostly fixed cost, then people like me are going to be calculating the point that it would be cost effective to do in house and then jump ship when we get to that point.

I agree here - if you tie to revenu and get too expensive (to me, over $500-100 a month), I’d find the dev time to replace this before we “overpaid”.

> over $500-100 a month

Businesses come in different sizes, and it's tempting to project startup-level finances onto your customers. But $100/mo is not an expenditure of note at most businesses. (Neither is $1k/mo, but that starts to be a different market.)

Some back-of-the-envelope math on costs for building a billing portal:

- First pass of Stripe integration including displaying receipts, upcoming bills, edit of payment info, etc. : at least two solid weeks to more like a month of dev time. Yes, most devs can get something shipped much faster. But to achieve a battle-tested, secure, reasonably complete implementation will take a few revisions. A month of dev time in the US will vary, but $10k fully loaded isn't out of the question. If you're using an agency, this could be much higher.

Other features your business may want will drive this cost higher: Salesforce integration, QuickBooks integration, operator-facing tools so customer service reps can see what the customer sees, etc.

But let's just say $10k+ of dev time for the implementation. Then don't forget you just added a bunch of code to your codebase that will need to be upgraded, tested etc. when you rev platform versions. If you added any dependencies specifically for the billing portal, congratulations on having your billing portal now drive your release schedule. The billing portal adds permanent technical debt to your project without helping you meaningfully differentiate.

For a small app, the billing portal code could reasonably be bigger than the rest of the app. I have seen this too.

Crucially, while you're building this code, you're not building code your customers care about. Zero of your customers would upvote "build billing portal" over anything relevant to why they are your customer.

Probably not true for everyone, but I would never implement this if it took a percentage of revenue. I made that mistake once. This is a very basic SaaS feature you can build out once and rarely think about again, or just grab a prebuilt starter SaaS setup like the ones I know of for Rails or Laravel and start with that. So I’d be on the fence about a monthly fee to begin with. But a percentage of revenue? Hell no!

Edit: plus, since you’re not driving new revenue, and replacing you is a one-time-fee (maintenance for this feature is minimal), all you’re doing with pricing based on percentage of revenue is pushing your largest and most valuable customers to get rid of you as fast as possible.

Sure, I was imagining not a percentage of the revenue, but plans based on how much revenue they are making with their SaaS tool. Ex.: If you make more than 10k MRR, you need to be on the Business plan.

I should have been more clear that I meant a linkage with revenue, which does not necessarily need to be a percentage. This helps at the high end and low end. Just quickly noodling this, I might define buckets based on revenue:

- free until revenue hits $X/mo (versus # of customers, this better tracks ability to pay)

- buckets defined as revenue of $X-$Y pays $Z

- max revenue tier is $X/mo, BUT

- pricing can go higher with more value-added services. Really common examples: SSO, Salesforce integration, QuickBooks integration, we'll call customers to find out why they churned, we'll proactively handle renewals of your customers who pay by PO (this is a PITA), and other things your $$$$$ customers will ask for.

Also: no pricing model will work for every one of your potential customers. And it's easier to lower prices than raise them.

Do you mind to list the existing starter setups in Rails/Laravel? Thanks.

Here’s a thread that might be useful: https://www.indiehackers.com/forum/recommendation-on-a-saas-...

> after having built N billing portals in the past

Quick question. Any recommendations for a "wallet library" for a web-app side project (either JS or Java backend) ?

Basically we want to take payments from users, charge the wallet for certain operations, and show history and balance.

I am not even sure what to google to find this.

Any pointers appreciated.

Any ledger software could fit the bill here, double entry journal.

That looks really nice for people who want to focus their energy on other parts of their apps.

Thanks!

I may be missing something, but are Stripe customer IDs considered secret? I never really thought of them as secret, and if they’re not, it looks like you’re opening up an unauthenticated API with read/write permissions on my Stripe account?

We are using your Stripe token in our backend to get the subscription information, and we also rely on identity verification to make sure that none of your customers can impersonate another one by guessing another Stripe Customer ID (https://docs.pubilling.io/quick-install/identify-verificatio...). Make sense?

Well yeah, it does make sense, but why is it not shown in the sample code on your homepage?

Good point, I was trying to make the snippet simpler, since this is not required for Stripe setups, but I agree that this should be more clear. Thanks for the feedback!

Sorry, now I’m more confused. Why isn’t it required for Stripe? The docs say it’s required for everyone.

What stack does it uses? Where is it hosted? Whag services does it uses?

The stack is Rails, React and GraphQL. We are using Heroku for hosting right now, but we are looking to move to AWS.

Nitpick but for the embed snippet, why not this simpler snippet?

    <script src="https://app.pubilling.io/sdk.js" async></script>

Thanks! I basically checked how other embeddable companies are doing, but you are right, I think it could be simpler now, thanks!

I like how you've generated "terms of service" & "privacy policy". But why not add those to your website, as opposed to 3rd party links?

We used third-party services to generate that, and that's why we redirect. We are looking to migrate that to our end in the future. Thanks for the question!

Do you (plan to) support (multiple) one-time billings ?

I am kinda of looking for a library to manage each customer billings and balance

I see you can check your invoices in the billing panel, but nothing about how those invoices are sent out?

We have plans to add this feature in the future, but it's not a priority today since Recurly and Stripe already send those invoices to the customers. Do you have any particular need for that? Thanks!

I don't, I was just wondering how the invoices are sent since in some countries you might have legal requirements for invoices that the solutions you build upon might not support. In reading the description (albeit quickly) I did not understand if Stripe was sending the invoices or you were just using them for payment, generating invoices sending, or some 3rd way.

Which made it hard for me to figure out if there were some possible requirements issue.

You've got a typo here in the FAQ:

>It's PuBilling another payment...

Should be

>Is PuBilling another...

Thanks for the help! Fixed :)

Do you support EU VAT?

We have support for Recurly but not for Stripe today, but we can easily add support for that. Do you have any specific need?

+1 for EU VAT, if you can automate how much VAT to charge whom that would make life much easier. VAT percentage based on country (default selection via IP location would be fantastic) and wether it’s a person or company. Killer feature since Stripe lacks any support for this and coding it from scratch is a pain.

FYI Chargebee handle EU VAT rules for businesses and consumers, if you’re looking for a solution there (it’s the main reason I started using them)

Missing a 0 in screen shot?

where? :)

Reply on news.ycombinator.com