#stripe

nikhil you can set it to `minimum` which will always be the lowest for your country. in the us you may get a 2 day rolling payout period

hi you can enable `debit_negative_balances` and stripe will try to retrieve funds from their bank account if their balance goes negative. https://stripe.com/docs/connect/account-balances

correct. well, you, as a platform, could refund the charge but not pull back the transfer from the connected account (but in that case your platform would eat all the refunded money for the transaction)

morning, I ran into an issue with Stripe some months ago RE number of subscriptions per customer

I was wondering why there were limits to begin with and perhaps what I was doing with this particular customer having 50+ subscriptions is the wrong way of billing?

hendry: generally 50 subscriptions for a customer means they're going to get charged 50 times a month which isn't great for you nor the customer

they're going to have 50 charges which makes it impossible for them to reconcile and you're charged the stripe flat fee 50 times which is expensive

mattwc: so how should I have handled this use case?

you can add items to the subscription, or use the quantity property on the subscription plan

mattwc: aka why is stripe not reconciling this for me and making me jump hoops ;)

this is painful to implement since new subscriptions are added one by one (by current design)

it depends a bit on how your system is set up, but you could just increment the quantity https://stripe.com/docs/billing/subscriptions/q...

or add a new plan to their current subscription https://stripe.com/docs/billing/subscriptions/m...

but incrementing the quantity doesn't make sense since the i would be charging inaccurately i think

imagine i have 30 subscriptions, added individually every day of the month

by default Stripe prorates

mattwc: oh

that includes the 7 day trial or whatever ?

the trial only applies when the subscription is initially created

generally you don't give people trials once they're already a paying customer

mattwc: hmmm true

so I should be thinking now, IIUC that each subscription is actually a "plan" ?

it depends a bit on your app, generally I think of subscription as someone signing up for your app, creating a new account, etc. then if they want more services, add ons, additional licenses, than that is adding a plan / updating qty

is 'adding a plan' the same as 'updating qty' or are they different things (sorry, just want to avoid confusion)

you can update the quantity of a plan a subscription has or you can add a new plan a subscription

you'd most likely want to update if they're going from 1 user to 2 users, but if they're adding a different product then you'd most likely add a new plan to the subscription

mattwc: thank you for answering my question

ok, new question. in light of https://twitter.com/jagthedrummer/status/103781...

iirc stripe has the notion of customer

customer would be the account in that case

and i think i have been mapping each user to a customer when creating subscriptions

so if I want to treat a customer as an account... how do in practically achieve this?

because i was hoping to be lazy and make a clean mapping to stripe and get locked in ;)

so that requires that your app have some sort of parent account, an account has 1 stripe customer, and then an account has many users that exist in your system but not Stripe

*that account has 1 stripe customer...

ok, so Stripe doesn't have that heirachy or whatever I can just use

nope, you'd implement that yourself

is https://checkout.stripe.com/checkout.js still the easiest way to implement some sort of a payment? since I am especially interested in leveraging Web payments

I think I saw some sexy Safari or Chrome demos, and I wonder if Stripe supports that flow.

I ask these questions since I am starting from scratch on this new project

thats going to be the simplest way to get a checkout form built, but if you want more extension-ability then you'd want to use Stripe elements, or if you want to use any of the alternative payments that aren't credit card you'd need to use Stripe.js

are there any demos / reference implementations of Web payments working via Stripe out of interest?

what do you mean by web payments?

like the apple pay / google pay in the browser stuff?

mattwc: yes https://developers.google.com/web/fundamentals/...

mattwc: sorry, I am not familiar with the maturity of this technology

mattwc: cool thanks

ok, another question

I am trying to understand https://stripe.com/sg/billing

i think it's stuff I've implemented myself before, but i am not sure

i guess it makes it easier to define plans and such in a gui, without code?

billing is just the standard subscription stuff as before just with some added features

the gui always existed to create plans

tbh i have had my own invoicing system before (using stripe), so i guess https://stripe.com/sg/billing would perform the same flows... but argh the devil is in the details

ok, this is a use case I think i need to be able to cover

user uses my app. user likes my app and wants to unlock premium. user fills in a form telling us who are the billing contacts for his organisation.

we then send an invoice to his organisation. organisation pays the invoice hopefully. user becomes premium.

can https://stripe.com/sg/billing support that sort of flow?

or am i best off just coding stuff myself

the one thing I don't think billing will do is wait until the invoice is paid for them to become premium

since generally you have the customer pay immediately, and you'd only do the sending of an invoice if the customer is large enough to warrant a purchase order type set up

yes, the delay for a billing dept to pay could be rather painful, but i think it would be saner for me only to allow the user to go premium once their billing dept swings into action

perhaps the system can accomodate me marking the user as premium although an invoice is outstanding? not sure

nontheless i am wondering if https://stripe.com/sg/billing will save me any time. i guess it's pretty straightforward in my brain to implement myself.

yeah with billing, the payment is due X days after the invoice is sent which would be at the start of the billing cycle

so you'd generally only want to use it in cases where you have a like signed purchase order agreement with a large customer or are doing post-service billing

yeah... don't want to be fixed in that neccessarily

mattwc: does https://gist.github.com/kaihendry/a4fd660a1ebfa... look sane?

do you plan on most of your customers being organizations with multiple users?

mattwc: not neccessarily

i am not sure if there will be mostly single users or mostly organisations of users

tbh i'd prefer mostly organisations of users from a business model perspective

so the one thing is generally an organization invites / manages users themselves as opposed to a user creating their own account and then like adding the organization's billing info

The typical flow is company a creates an account, the account admin then just invites user's B, C, D etc...

the company account is then configured with a credit card or for invoicing, etc

i understand, but the flow i have proposed here, i think is more accomodating to both scenarios based on preivous experience

because both the individual user and the organisation of users can be accomodated with one flow effectively

(hope it made sense)

in the flow I explained it still handles individual users and organizations of users though?

an individual user doesn't invite any extra users, and an organization invites extra users

i suppose

and from a point that the tweet was trying to get to, you're going to want to know the account a user belongs to before creating it

(this has to do with the eventual need to likely shard your database / scale databases / services / etc)

but the cool thing about have a billing contact form as I proposed is that is clear from the outset

there isn't a notion of a user is migrated to an account by adding billing info, billing is seperate