#Nukesforbreakfast
brazen cloak
steep herald
Hello! I don't think you can model that pricing with Stripe. You would likely need to do the calculations on your end to determine what to charge them for each month, then create a monthly Stripe Subscription for that amount.
silent mist
I was thinking maybe there was something that could be done using aggregate_usage=last_during_period
steep herald
The closest thing we have is usage-based pricing, but it does not accommodate your use case as far as I can tell: https://stripe.com/docs/products-prices/pricing-models#usage-based-pricing
silent mist
so the interval on the price controls the usage period?
so an annual interval would, by default, sum all usage for the year? Whereas a monthly interval would sum all usage for the month?
steep herald
Yes.
silent mist
ok, so there's not a way to decouple the pricing interval from the usage period at the moment I take it?
steep herald
Correct.
silent mist
ok
- feature request! 🤣
- you mentioned "monthly stripe subscription"s. I'm not sure I follow what you mean. Would you please elaborate?
steep herald
You want to have people pay every month, correct?
Flagged your feature request internally. 🙂
silent mist
yes, I want people to pay monthly
ideally on a calendar month period, I.E. the billing period is from the first date to the last date of the month each month.
steep herald
Okay, so what you would do is calculate on your end how much you want them to pay monthly, then set up a monthly Subscription for that amount.
silent mist
when you say "monthly subscription" do you mean a subscription that only lasts for that one month? The monthly price would change based on the usage per the graduated tier I mentioned above.
steep herald
If the amount changes every month you might be better off not using Stripe Subscriptions and instead issue a one-off Invoice every month for that month's amount instead.
silent mist
ok. That was the original assumption, but then I saw the advanced usage based pricing page and it almost worked for our pricing schedule.
steep herald
Yep, we don't have support for the exact pricing structure you need.
silent mist
close but no cigar.
I have a different line of questioning about helping pick the right connected account type/structure.
- is this discord the right place for that kind of question?
- if so, should it be a different thread?
it's sort of a solutions architect line of questioning.
steep herald
That's probably a good question to ask on Discord, yeah. You can ask here, don't need to create a new thread.
What do you mean by "a solutions architect line of questioning" exactly?
silent mist
it's not really a technical discussion per-se: it's more of a "here's my business model and XYZ considerations that make it unclear to me whether Standard or Express accounts are better for my use cases. Can you help me decide?"
steep herald
Yeah, what's up?
silent mist
OK, so we currently use Connect with Standard accounts because I was rushing 3 years ago to get something in for a demanding customer. I'm not sure it was the right call anymore.
We contract with Cities/Municipalities to manage their False Alarm Ordinance which governs things such as permit fees for alarm systems, fines for excessive false alarm activations (hence the graduated tier above), etc. The main use case for stripe is to allow users to pay for their permit fees and fines online and bill them on a monthly basis based on the number of false alarms.
There are two business models:
- the City in question outsources the entire function to us where we essentially function as an extension of their staff. We essentially impersonate them and handle all aspects of their alarm ordinance administration.
- the City in question does the work themselves, and uses our product as a SaaS to help them do the work.
In all cases we would want to be impersonating the City so everything would be their branding, their statement descriptor, etc. However, in model 1 it is normally some kind of revenue share where we split amounts collected, but in model 2 it would likely be some kind of usage based pricing. I can't rely on the application fee parameter to collect our cut in model 1 as a lot of payments come in out of band via mailed check so we would be closing some invoices as paid out of band.
Also, a lot of these folks aren't super e-commerce online payments savvy so having a full dashboard might not be the best idea. However, their accounts receivable and payable departments likely need a better transaction export function than the current express dashboard provides in order to reconcile the fee and fine accounts and validate the amount owed to us in the revenue share case.
steep herald
Hmmmmm...
silent mist
right?? It's like a hybrid.
steep herald
For #2 I would think Standard accounts would be best.
For #1 I'm somewhat on the fence, but leaning toward Express. You can always build the reporting they would need on your end to augment the Express Dashboard.
silent mist
for number 1 right now what we did was standard accounts with destination charges and on_behalf_of
steep herald
We do not recommend using destination charges with Standard accounts.
silent mist
I'm fully aware
not saying it was the best decision I ever made...
For #2 the thing I'm concerned with is: My understanding is Stripe Invoicing charges some % based on paid invoice volume, regardless of how the invoice was paid. So if they're processing checks and our app closes invoices as paid out of band, they're still getting hit with a 0.4% fee or whatever. And it also begs the question of how to manage the different pricing tiers for features of Stripe Invoicing when using a Standard vs Express account.
steep herald
I'm not sure how the fees work with out-of-band Invoice payments, that's something you would need to ask support about.
silent mist
they stated it would be charged for the volume of paid invoices, regardless of how the invoice was closed as PAID
steep herald
What I recommend is having a careful read through of https://stripe.com/docs/connect/charges and compiling a list of questions to send to support so they can help you get the answers you need to make the best decision for your needs.
silent mist
so my understanding is if I processed $1000 of invoices via check, Stripe would debit my stripe balance for 0.4% of that.
steep herald
Ah, okay.
silent mist
or the connected account's stripe balance in the standard account, direct charges case.
steep herald
Well, with direct charges (what you should use with Standard accounts) they would debit the connected account.
Ha!
silent mist
ok, so one last question I think
you say that it is discouraged to use destination charges with standard accounts. What about direct charges with express accounts?
similarly a bad practice?
silent mist
ok. Interesting. The UX of mixing different account types seems problematic. Maybe.
steep herald
UX for who?
silent mist
the City. The end user making the payment probably won't notice a difference.
so much to consider
steep herald
Yeah, it can get complex for sure. What specific UX concerns do you have?
silent mist
the City not knowing the power they have with a full stripe dashboard and maybe breaking something by manually performing actions there.
If we have a city that we were using model 1 for but then, due to say a recession, they want to bring it in house and switch to model 2, there's no easy way I'm aware of to swap their account type from a Standard to an Express or vice versa.
steep herald
That's true.
If you do have situations where people switch back and forth that's a strong argument to have a unified approach (probably Express).
silent mist
I'm thinking the right call is express because the lowest common denominator is they're not really going to be using Stripe to manually do anything from the dashboard. It's likely going to be done via our application in some way or another.
steep herald
Yep, makes sense.
silent mist
ok. Completely different question I just thought of:
Is there a way to dynamically price an invoice based on the payment method used? I hate the practice, but some cities will be adamant that they want to charge a "convenience fee" for card payments but skip it for ACH debits due to the lower transaction fee cost.
hushed night
👋 i'm stepping in now since @steep herald has to head out
silent mist
thanks @steep herald! Have a merry christmas!
hushed night
Hmmm... is it a hard requirement for you to create the Invoice BEFORE the use locks in their choice for which payment method is selected? Like are you relying on somethign like our Hosted Invoice Page to collect payment (so the Invoice needs to be created up front and the user makes their choice there), or do you have your own UI?
silent mist
I mean we built some crappy notion of an "invoice" before Stripe was a thing for us, so actually we let people pay those via checkout currently. But I was considering moving to using Stripe invoices to get a lot of the features that come with using those.
hushed night
Gotchaaa
silent mist
and if we do, since it's a monthly billing cadence, I'm guessing we would have to create that invoice before the user selected their preferred payment method. It would likely be lots of send_invoice rather than auto_collect
hushed night
So having to dynamically price an Invoice based on the payment method used is actually pretty tough - Invoices have a lot of strict compliance-related rules, and so it's much harder to update them once they've been finalized (which is a necessary step before payment)
What specific features of Stripe Invoicing were you interested in? Checkout also has the ability to generate an Invoice after successful payment, but I'm assuming that's not what you want
silent mist
automatic follow ups for overdue invoices, being able to listen to those webhooks and trigger other processes like:
Invoice overdue event triggers a notice of violation to be emailed/physically mailed to notify they will receive additional penalties if not paid within X days.
I'm not sure it's a hard and fast rule to need to support this "convenience fee" use case, but I have seen it asked for before.
The whole branded flows and branded PDFs are useful as well. Customer invoice number sequencing would be useful too. There's a lot of utility in the way Stripe does invoices that we would have to replicate ourselves, so why not use what's already built?
hushed night
Yeah that's fair - there are some people who want the convenience of Checkout combined with Invoices (which is why we built that feature for generating an Invoice after a successful checkout session), but it sounds like you're just purely interested in Invoices
silent mist
it's become abundantly clear that a concept of a "invoice" feeds into many other business processes, which requires it to exist before a payment is made.
in our case anyways
hushed night
Going back to your original question - there isn't really a way of dynamically updating the Invoice based on the PaymentMethod type they choose. You'd have to void the original Invoice and create a new one to reflect whatever fee you wanted, or look into our edit invoices features (https://stripe.com/docs/invoicing/invoice-edits). Another alternative would be to bake the highest fee into the invoice by default and then issue a credit note (https://stripe.com/docs/invoicing/dashboard/credit-notes) if they end up using a cheaper payment method type
silent mist
invoicing edits was actually something I was looking at for another feature we sometimes have. Cities will sometimes put users on payment plans if they can't afford to pay the whole bill all at once. A one-off subscription type arrangement seems like it would be perfect for that. But, is there a way to link that old invoice to the new chain of payment plan invoices that pay for that original invoice?
hushed night
Editing invoices won't really work for that - yes, any Invoice that is gnerated from an edit will be linked to the original, but once that Invoice is paid you can't edit it anymore so you can't split out one Invoice into multiple Invoices and have them be linked together.