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.
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.
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.
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?
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!
+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.
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.
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.
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!
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.
53 comments
[ 2.9 ms ] story [ 38.7 ms ] threadHeads 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...
Google Chrome Version 71.0.3578.98 (Official Build) (64-bit)
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.
https://gfycat.com/EssentialUglyHarborporpoise
>It's PuBilling another payment...
Should be
>Is PuBilling another...
Which made it hard for me to figure out if there were some possible requirements issue.
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).
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.
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.
- 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.
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.
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.
I am kinda of looking for a library to manage each customer billings and balance
https://www.servicebot.io/pricing
https://www.chargebee.com/pricing
this one is free: https://www.chargebee.com/open-source-customer-portal/