#stripe

lrotherfield: 0019 and 4954 are both highest risk, and normally charges with the highest risk level will always be blocked. The 4954 card is just special though, you're right. It's to help simulate would hypothetically happen if you had disabled that default rule. It's admittedly confusing.

Great thanks, I understand now.

joeearly: it looks like you could just move the event listener function at the bottom up into the document.ready function and that would fix the issue

joeearly: hmm, you could try adding a unique per-modal ID to each `iban-element` DOM element, does that make sense? But I see your issue alright.

joeearly: like, when the modal opens, you can create a new DOM element with a unique ID, and the mount the IBAN element to that. It does add some more complexity though.

Hello, for a monthly subsciption which let's say has right now (before new invoice) has current_period_start )A) = 1000 and current_period_end (B) = current_period_start + (30 days more converted in seconds)

An invoice.payment_succeeded will have the new dates current_period_start = B and current_period_end = B + (30 days more converted in seconds)

is my assumption correct?

diegoaguilar : yep!

thanks koopajah

I'm writing a bunch of Stripe integration functional tests

you think there's a chance I share with someone from dev team?

I look for feedback and prob at the end, just sharing

sure you can always ask us for feedback

that name is note banned so not sure what he meant

not*

Nevermind - seems to have resolved.

yes I double checked you were not banned

Must have been a bug with my client.

abenrob not possible no

hello, is there a way to make sure that multiple transfers will be made separately, even if they occur at the same time, and to the same account ?

aguilbau : not sure what you mean. If you create 3 transfers, they will all be separate

Guest99270 : that means their last invoice was not paid

what i mean is that they will recieve it in one time, on their bank account

and that's the behaviour i would like to change

aguilbau : Transfers are not sent to a bank account, they are sent to the balance of a connected account. Payouts are what are sent to a connected account's bank account

Guest99270 : you just ignore it and start a new subscription, it will just work.

oh ok, so then that's probably where my problem lies. thanks !

Guest99270 : the fact that it has `delinquent: true`. It does not matter at all to a new subscription

so to achieve my result, I should initiate a payout on each transfer, right ?

Guest99270 : when you try to create a subscription it should tell you exactly why it does not work

aguilbau : yes

what's the invoice id?

Okay so if you look at the invoice it tells you exactly what happened.

you switched plans at a time where the coupon was not active anymore. So they had paid less than the original plan amount

so it's kind of expected behaviour in that case

so they got the credit for the used time (with the coupon) and then they owed you for the remaining time at the new price point (without the coupon)

if you wanted to change the plan without having them start paying more, you needed to disable proration on the upgrade. If you wanted them to start paying more though that's what we calculated. The discrepancy/what confuses is because the proration happened when the coupon was not applied anymore

Sure but when we *prorate* we use what they *paid* (coupon included) not what "they would have paid without the coupon"

you did not since there are 2 pending invoice items because of that change

https://dashboard.stripe.com/logs/req_yiAGiZVqO... that's the upgrade request and you see `prorate` is not there

ricebear : the funds should become available immediately. Are you sure this account did not have a negative balance at the time? Did you check what their balance was before and after the transfer?

ricebear : sure but taht's *now*. Was that the case when those errors happened yesterday?

Larrik : sure1

sure*

If I use a saved card on a Customer for a Charge, delete the card from the Customer (or change the default card), and then refund the Charge, will the refund always go back to the original card that was charged?

nratter : yes

thank you...

one other question... is there any advantages to detaching a card vs deleting a card from a customer object? I see you can do both.

nratter : detaching is for *Sources* and deleting is for *Cards*

but aren't cards added in sources?

Larrik : yes you would call https://stripe.com/docs/api#delete_invoiceitem for each pending invoice item (or do it in the dashboard). And because what if you upgrade the plan 10 times a day? That would be painful to have 10 charges a day. So by default we calculate proration. https://stripe.com/docs/billing/subscriptions/p... covers this in more details

nratter : not really, Card objects and Source objects are entirely different

ok i'll look more through the docs. thanks again.

ricebear : I'm just asking. Unfortunately it's not really something I can debug here, you'll have to write in in that case

no I don't have a suggestion I'm sorry. Someone would need to investigate the exact balance on those accounts. I would recommend sending detailed information to our support team about each case

Guest76605 : yes it works with invoices too

What's your question?

I don't think that's explicitly available in the API