#stripe

I think `java.util.Date` uses UTC by default

I am confused between timezone and UTC , what is the difference

UTC is a timezone

But UTC can be different for US, Asia

no, UTC is the "neutral" timezone

is it the case ?

Okay

So I need to set the server to UTC first

?

If you use `java.util.Date` you shouldn't need to, it will return times in UTC

not necessarily, but running your server on UTC tends to make things easier

Okay , I am using java.util.Date

that said, yep, plenty of server administrators choose to use UTC to make things simpler

it's a huge pain to run a server on local time, because you get to deal with daylight savings twice a year

at an old job, the servers were run on a local timezone, and we'd get the weirdest bugs twice a year when passing through daylight savings

Ubuntu can be setup in UTC

yep

you can set the timezone to UTC on pretty much every OS

Cool

Chetan: http://askubuntu.com/a/138442 explains how to set a Ubuntu server to UTC

Hello

hi Chetan_

If the recurring payment fails , then after how much time the it happens again

Chetan_: you set that in your retry settings in your Dashboard's account settings

How many times it tries , the maximum attempts

Can we get the reason why it failed

Chetan_: how many times it retries you can set yourself in your account settings

Chetan_: a failed invoice billing will leave behind a failed charge, which will have a failure_code

thanks @ywain

though it would most likely just be a card decline

well, yes

gtripoli: you're welcome!

it's probably going to be either an expired_card or a card_declined

and the bank will sometimes report expired_card as card_declined

Okay

Hello all , when we consider the web hooks for the recurring plan , does stripe charges for the customer

or other end should charge it

Chetan_: I'm not sure what you're asking

for subscriptions, stripe charges the customer

you do not manually create the charge

ok

@tr12 : I am asking about the recurring payment webhooks

if the plan is recurring

I don't know what you mean by "consider the webhooks", though

@markin: This applies only for the recurring

Correct

the purpose of the recurring plan is so that stripe does the charges

Okay

also I did not understand invoice.created

event

It is stated that it waits for the 1 hour

for the webhook

an invoice is created and 1 hour after the invoice is charged

My understanding is it charges for the customer then it calls the webhook

hello, would someone be able to explain to me the meaning of "default" for a source

@markin: then when the web hook will be called

mosthumancompute: a customer can have a default source - if you create a charge and specify a customer, but not the particular card attached to that customer that you want to use, it'll use the default

i'm trying to create two subscriptions with each using separate source

i see

Chetan_: it does invoice.created then 1 hour after it charges the customer and sends the paid webhook

mosthumancompute: all subscriptions draw from the default source

mosthumancompute: you'd need 2 different customers then

mosthumancompute: you'd need to create two separate customers to do that

even if in my system they would represent one?

with 2 subscriptions

yes

yes, so your database can do the logic to tie them together

got it, it's a bit odd i'd say :-)

invoice.payment_succeeded

Chetan_: that happens after the payment goes through

So we can use this event for successful charge

Chetan_: yes

mosthumancompute: yeah - this is known to be a missing feature

Can we get the exact reason why it failed to charge

Chetan_: that would be in the charge.failed/invoice.payment_failed webhook

that means charge.failed and invoice.payment_failed are the events

@tr12 yeah that does complicate things a bit, do you know if and when this may be addressed by any chance?

Chetan_: those are two seperate events that happen when the payment fails

Which one needs to be captured

Chetan_: thats for you to decide based on what information you need

mosthumancompute: the difficulty is that you wind up having to keep track of multiple customer balances, and some work would need to be done to decide the best way to present that in the api

I need the reason for failure

Card expired

Chetan_: so that would be in the charge object of the failed charge

Which are the various reasons

charge.failed

So both events happen at the same time

Chetan_: yes

for the failure reason, please refer to https://stripe.com/docs/api#charge_object-failu...

it does not contain the failure codes

it contains http status codes

@tr12 i see what you mean. thanks for the info, this really helps.

Chetan_: it has the failure codes, the status codes would only be a 402

Chetan_: you'd see a table titled "Codes" that has like "incorrect_number"

@markin : Thanks

@tr12 seems like a possible way to do it would be to keep track of balance per subscription

mosthumancompute: that would be backwards incompatible, though

the right division seems to be a balance per card

would that be backwards compatible?

there's a plausible way of implementing that which would be

the idea being that at the same time as you go from n subscriptions drawing from 1 card to n subscriptions drawing from m cards, you go from 1 balance to m balances

gosh that seems to complicate the api a bit, I prefer the one customer per card method

so there's no way to create a situation in the old world which drew from a single balance that would draw from multiple balances in the new world

well yeah

this is part of the reason it hasn't been tackled yet

yeah now that you went into the reasons a bit more i can see why not

in general, building new features while maintaining backwards compatibility is a very delicate dance

it's a fun problem, but also really frustrating at times

maybe creating a concept of a "parent" customer could be a solution?

since this is how the problem was addressed already - using multiple customer accounts

possibly - some sort of inheritance of parameters

that sounds like a plausible solution

right so you manage the customer at the higher level then the payment methods can be at the lower level

there are some ways to hack that using shared customers,

that does seem like a possibility but at the expense of manageability

once you have a lot of connected accounts

and customers

not sure which problem i would rather have

there is increased manageability even if the api supported it

I think the simplest would just be one card per customer, and you can link customers together using your database

or you do the recurring logic yourself and just create one off charges

with connected accounts people tend to do that so the connected account doesn't have access to the card data

i prefer to stay away from implementing the recurring logic even though it always is very tempting

to code everything yourself :-)

for now i think i'll stick within the limitations and just have one payment method for all subscriptions at a time

hi there :) how are you all.

it was a question :)

So I’m here asking for strip security issues. anyone?