#anthonyg-customerportal
simple anchor
@bronze barn yes that still works. Also really easy to just test to confirm. I know I say that every time and I hope it's not too annoying but it's often faster to test than to try and ask us
bronze barn
Hahaha, no not annoyed. Sorry if my constant questions that could be test annoy you!
In this case, I don't have anything about customer portal setup or working, so wanted to know if it would even be usable before setting it up.
simple anchor
yeah that makes sense. But it still would take you 4 minutes to write code that creates a customer and a customer portal link 🙂
and it doesn't annoy me or anything, but I want to make sure I don't appear out of line when I say "did you just test" 🙂
some developers sometimes do not take kindly to that question 😅
bronze barn
Hahaha, wait by some developers you mean Stripe customers who are developers being asked that by Stripe dev-support, or Stripe dev-support being asked questions by customer developers that ask questions before testing?
I found the customer portal stuff confusing and thought it would take me longer to setup as we don't really have a front end for customers that I can integrate it with. Our public site is crap and we need to shift platforms.
simple anchor
the former
Like when someone asks a question like yours and I say "what have you tried? What error do you see?" it does not always go well!
And you don't really need anything pre-existing to test the customer portal. You should see my own repos, I have hundreds of one off small PHP scripts to test everything our API supports
bronze barn
Anyway, reason I was asking about the customer portal working not related to subscriptions is because I was starting to think that maybe we should ditch subscriptions all together and just bill our customers with one-off invoices whenever needed using the API to finalize and pay, etc, and automate that on our end instead of using Stripe subscriptions to automate so we can bill each of our 9 or 2 or 1 installments on whatever dates we want. Anything we're loosing doing this as opposed to subscriptions though from the Stripe features / functionality perspective?
simple anchor
so you'd just do a really simple/basic script in your language that would create a customer with payment details and then redirect to the portal. That's like 20 lines of code at best and you can then easily modify this to iterate on, completely separate from your current integration
And you'd lose things like revenue recognition and proration for example. But based on your current business model, that seems like a better flow overall
bronze barn
Yeah loosing proration doesn't affect us at all right now as we don't prorate based on how Stripe does it. It's a manual thing for us anyway using invoice item credits basically. So revenue recognition we'd loose, but to be honest we estimate that our own way too I think since we're a school based tuition type model and not a month to month subscription service. So I guess we wouldn't really be loosing anything then, at least for the current business model.
We can still associate one off invoices to products / plans to get the right pricing though? Or would that all manually need to be created for the invoice each time?
Or wait, invoice items need to be created first, which are associated with price objects, and then the invoice gets created after and those get pulled in.
simple anchor
yeah it will still just work, the flow is a bit clumsier since we don't yet support the "create an invoice with a line item" but otherwise it's fine
bronze barn
Yeah, why is that, since you can specify on an invoice item what invoice it's associated with?
simple anchor
mostly prioritization. We could build that. Or we could build the dozens of new features we've built instead like automatic tax calculation
We want to, just the workaround is not that bad and so we haven't really prioritized improving the creation flow yet.
bronze barn
Makes sense
Means we can't create invoice items ahead of time and associate them with an invoice that's in draft and set to bill at a future date though I think. Or maybe there's a way to do it that way so we can just pay the invoice on the date it's due. I haven't explored that yet and the difference between auto collection and email to client. We don't want to email and have the client pay, but we would maybe setup the invoices in advance or something if we could.
simple anchor
yeah you can do that and keep the invoice in draft for as long as you need with auto_advance: false and not finalizing it
bronze barn
But then given that invoice items have to get created first when new items are created they'd automatically get pulled into the first draft invoice created. So if I had 3 items for invoice #1 and 3 for invoice #2 when I created items 4, 5 and 6 they'd get automatically associated with invoice #1 when created right?
simple anchor
well you'd create item #1 and then invoice #1 so that it's pulled in, when you create item #2 either you add it to invoice #1, or you create a new invoice right after to have it pulled in that new invoice
bronze barn
Woah, seeing some new functionality with coupons. Last I checked (which was a long time ago) you couldn't stack coupons (so not more than one applied). When did that change??
lilac bolt