#stripe

you must not be passing the API key properly, look how we do it in our bindings and copy it

So there is currently no way to test retrieving bank account info?

ryebred: I don't remember talking about that I'm sorry, it's not my day. What are you trying to do exactly?

Sorry it was very early this morning. I am using the Java API and I am trying to get the bank account associated with an account

Something like Account.getBankAccounts()

what account

But there is no such method

standalone, managed, yours?

in the Java api

managed

so yeah https://github.com/stripe/stripe-java/blob/mast... doesn't seem to have this. out of curiosity why do you need this?

To display to the user the last 4 digits of their bank account so they can select/confirm the appropriate one for us to deposit their money into

aren't multiple bank accounts not publically documented and thus not in the api libraries?

yeah I mean this will get added in the near future and I'd wait if I were you

also I hear rumors bank_accounts is going to be renamed destinations or something before they're documented

unreliable rumours :)

@koopajah

@koopajah i read that doc

@koopajah our customers get seperate invoices for each subscription

ryebred: so I think you need to modify the bindings to parse the JSON we send for the account that seems a bit overkill if you can wait a week or two

and it appears that the prorating occurs within each sub, not across them. is that right?

danw_: I don't get it at all. You have two plans. You move from plan A to plan B. That's it

don't try and set quantity to 0 or something

@koopajah they're paying for a quantity on the sub

@koopajah it's not just moving a customer from one sub to another

but you're moving them to another plan

I have no idea what you are trying to do and what's blocking you I'm sorry :(

danw_, prorations are applied to the credit field of a customer object, not a subscription.

setting quantity to 0 seems weird, and I'm a bit surprised its allowed

danw_, and a 0 quantity subscription makes that subscription free. it will always be "active"

markin, it's for free stuff

ne0n: it seems like a free subscription or a 100% coupon makes more sense from a semantics standpoint

@neon @koopajah i don't think i'm describing this very well, i guess

yeah, I'm just saying how it works.

danw_, I went back and read some of the stuff you said, and I think you're basing what you want to do on false information.

danw_, what are you trying to do from a higher level. Move your customers to a new plan?

hey guys, had a quick question - if a card token is not associated with a customer object, does it expire?

lets use an example, like slack

we run a saas product like slack

asteros: we only guarantee that it works for 5 minutes

we offer different pricing tiers

sure

so does my company.

great. we want to be able to allow an admin to pay us for the nubmer of people on different tiers

5 people on basic, 5 people on pro

lets say that basic is $5, and pro is $10

You might want to check out Invoice Line Items.

wow, yeah I get it now. Just update the quantity on both subscriptions with proration: true

if someone upgrades all of their basic team members to pro, what we are seeing is that the basic invoice has credit line items

if we prorate it

and then either create an invoice *now* to charge as expected or let future invoices settle this (as you set invoice items would be on a per subscription but end up on the account balance)

so they pay for pro, and we aren't truly crediting them for the basic they aren't using anymore

danw_, that credit gets applied to the customer object even though the line items show for the subscription

their invoices only have line items for the sub

yes

so how do the customer credits for the basic plan get applied to the pro subscription?

those two subs will get two charges on the credit card and two invoices.

there is quantity 0 on the basic sub

but we don't refund the balance on the basic plan

danw_, well, first you should delete the basic sub instead of setting the quantity to zero.

ne0n: if you do that, you won't get the proration calculated

Hi!

danw_: it's pretty easy/straightforward and it would work. Just try it in the dashboard and you'll understand it

danw_, when a proration happens, it shows up as a line item on an invoice. The credit that is given to the customer is not returned to their card, but instead added as a credit.

@ne0n exactly

it's a credit on a sub and they don't get a refund

danw_, when the next invoice is billed, it will pull any available amount from the credit first, then bill the card.

danw_, no, it's not on the sub.

danw_, it's on the customer object.

ne0n: the edge case here is what if the basic subscription renews after the pro?

just invoice after both updates

markin, good point about the quantity and proration.

is there a limit on number of different plans I can create via API?

personally, I think it would be easier to just do this yourself, so that you're not charging the same customer multiple times. Just have a free subscription, and add line items each month for the different tiers

jara: nope

danw_, what's the problem. Do you want the refund to go to their card?

thx!

is there anyway to calculate a prorated subscription change amount before actually changing the subscription?

@ne0n yes we want to give them their money back on the plan they're moving from

when they move all of the seats

danw_: give it back or apply it as a credit to the pro plan?

koopajah- it's not documented, but can we send a DELETE request on a managed account to remove it? maybe it was created in error or similar and we don't want it hanging around?

markin, I agree. My company used to have a "base subscription" and a "additional user" subscription that we updated the quantity for. PITA. two invoices, two charges. two different subscription statuses. What if one's paid and one's not?

briang__: nope

markin: tnx

i want the user to get their prorated value back

danw_: what I'd do myself would be to decrease the number of users on one sub first, then invoice => credit in the account balance, then do the second proration

danw_, it doesn't work like that. You can give them a credit on their account, but it's illogical to give a refund. You're paying fees for that.

danw_: makes no sense to give money back and then charge even more later

koopajah: gracias

if it's on the pro sub, great. but as of right now, it seems like it isn't getting refunded to the user on the basic sub because it has quantity 0

good point

danw_, are these different stripe customers or is this one customer with two subscriptions?

the issue is that they aren't getting the value back

danw_: it will be applied to the pro subscription, if immediatly after the quantity change, you create a new invoice and "pay" it

box: np! sorry I thought it was danw_ asking because we're in the middle of the same kind of discussions :p

it's one customer with two subscriptions

danw_, we're telling you the account credit is fine. You keep seeming to think the base credit won't apply to the pro plan. you're wrong.

danw_: you're totally over-engineering it instead of laying it on paper and thinking about it. What's the point of giving $5 back and then charge $10 for the move to the new plan

one more - right now we have individual stripe accounts in us, canada and australia where we're domiciled (and we have marketplace enabled in us/canada right now) - my reading of the docs says that we can use just one of those accounts, put our USD, CAD and AUD bank accounts on our platform account, and then use the destination parameter to settle in any supported currency.

(sorry if that came off blunt)

If we settle an AUD charge, the application fee will go into our AUD account. But if we settle in a currency we don't have an account for, like GBP, it would get FX'd to our (default?) account - is that correct?

briang__: I think so

so basically if we charge for a destination account in USD/CAD/AUD, it will hit our rspective bank account - all others would get FX'd?

we're thinking about how to do this right

i'm not saying i wnat to explicitly do the refund

but the issue we're seeing is that the credit isn't applied to the pro plan

can a subscription be updated to the same subscription in order to trigger a web hook so we can add addons?

box: no

danw_, it should be, but we can't really help you without looking at your situation. There's probably some kind of edge case that I'm not seeing from what you're describing.

danw_: hopefully this explains it https://gist.github.com/matthewarkin/7f704aa75b...

cool, thanks for talking me through this

danw_: trying one last time: decrease the quantity on the basic plan, then create and pay the invoice, then the credit is on the customer's balance, then it's used on the pro plan's future invoice

i'll try to find an example where it isn't working like you guys are saying and contact support

ha what markin said exactly, been saying that over and over lol

koopajah: yeah, I was more going for the formatting :)

koopajah: 90% of communication is not what you say but how you say it :)

I would have said that 90% was being heard but ¯\_(ツ)_/¯ :)

If I have a subscription to rebill monthly does the invoice rebill happend at the same time of day every month for the given user?

yes

thanks

Can I get an update on what is going on with my balance to stripe migration? (what the problem was, ETA, etc)