#stripe

but the differences are quite nuanced

then I don't get how you're implementing the concept of account then

billing contact = account

billing contact e.g. billing@example.com becomes https://case.unee-t.com/account/billing@example...

so I sign up for an account, try it a bunch, decide I want to upgrade to a premium account, and I add my company's info as the billing contact, what happens to my user?

nothing until billing contact pays at https://case.unee-t.com/account/billing@example... (and approves association)

yeah I'm asking about when they approve that association?

you're going to do a migration then?

it just seems like you're going against the standard way to do this, and I don't see a great reason to not do it the standard way

you're probably right

though getting back to your question, there is no migration. once association is made, user is marked as premium.

and under "billing@example.com"; WRT billing

yeah, but that tweet is talking about the need to have accounts that manage multiple users because companies want / need that type of control, and then on the application side, you'll likely want to be able to shard your data by accounts which can become a very large refactor so it should be organized like that directly

I don't quite follow, accounts can be managed from https://case.unee-t.com/account/billing@example... ... users can be approved or kicked off.

i am implementing this from scratch, so it's not a migration from an existing system

don't quite understand your sharding point.

Is there any data that needs to be shared across users? If so what happens when that user is kicked off

sharding becomes a problem if you have 1 really big user/organization and you're like "okay lets move them over here" or if you just want to split load and you split users between 2 databases, what happens if the org is in 1 database, and when a new user creates their account they get created in a second database

if user is kicked off, then ummm... good question. the user loses access to the system. the system is effectively a collaborative bug tracker, there is always going to be someone else who can view an issue created by someone else if that makes sense

so let's talk about the "right way" to do it.

create an account, invite users.

what happens if user is already using the system? they approve to get assimilated by the account? can they choose to leave?

or do you mean by inviting, they are straight up new accounts?

the typical would be to have accounts, invite users, users are owned by an account, a user cannot be in multiple accounts, a user alone is their own account

this depends on what you're building, in terms of collaborative bug trackers, you have the github model

users can belong to multiple organizations, any advanced features belong to the organization and the organization pays for those advanced features

mattwc: thanks, I should have looked to Github. Lots to think about.

Guess the invite model is better, I just throught the opt in model could be faster since org might be slow or the bottle neck. but tbh it's premature optimisatoin

orgs are generally going to want the control to manage their own users as well, people opt-in / asking to join can cause them some security issues

well i would only allow opt-in if the @domain was the same, anyway it's silly

i wonder how github handles the case when the org stops paying ... I guess private repos become inaccessible

yeah the private orgs become like read only and stuff

I'm trying to get rid of my payment request buttons on the single and product page, can someone tell me what files the code from the faq need to go into? ie) add_filter( 'wc_stripe_hide_payment_request_on_product_page', '__return_true' );

for woocommerce

functions.php that's what it was, im tired :p

LucW: I think that's a setting on https://dashboard.stripe.com/account/recurring

`Email customers about… Failed payments`

oh right, oops

LucW: in that case you would have to build your own solution using webhooks to trigger sending an email from your own system I'm afraid :/ I'm doing a quick test to see what event you would receive.

LucW: not that I'm aware of unfortunately. I'm not sure why we have that restriction on the email actually, I'll try raising it internally to see if it's being tracked

LucW: the best way is to write into https://support.stripe.com/email with the feature request and they can check with the team.

LucW: no, `email` is a separate property on the customer object than their payment sources so I don't think it's that

LucW: it's most likely because it's not technically a payment failure, since there is no actual charge being attempted, so it's a separate class of problem. And since your integration is what controls whether a customer has a payment source or not, we leave it up to you I suppose

stripe968: the balance transaction has a `source` field which would be the charge ID: https://stripe.com/docs/api/#balance_transactio...

stripe968: the way to do this is that when you receive a payout created event, you list balance transactions and filter by that payout ID : https://stripe.com/docs/api#balance_history-payout , and expand(https://stripe.com/docs/api#expanding_ob... the `source` property. Then you can look at the returned balance history objects, they'll have the related charge objects embedded in them

stripe968: no, even if you do a manual payout, the funds in the payout are connected to the charges that added those funds to your account balance, so you should still be able to get the charge IDs.

stripe968: yes, you might be right, sorry, I misunderstood you.

stripe968: sorry, what's the question?

stripe968: a payout can have funds from multiple charges in it. So you have to do the filter approach I described to get the full list of charges included in a particular payout.

stripe968: I described how to do it earlier. The balance transaction has a `source` parameter which could be a charge ID.

stripe968: yes.

it's really just that ^^

stripe968: yeah, because with a manual payout there is no link to the original charges I believe, so the `source` is just the payout itself.

stripe968: the easiest way is to use the first card from https://stripe.com/docs/testing#cards-responses and process charges using it. Those funds become immediately available for payout. If you're on automatic payouts a payout will be created every day and fire the correct webhooks

you can't force an automatic payout, so you will likely have to do this over a couple of days basically

sef_: we recently changed the retry schedule so it's not once an hour anymore — instead it's very frequent closer to the event creation(to give you a faster retry in case of a server blip), but then it drops off over the next couple of days. You should get a retry later.

sef_: if you have the event ID I can take a look for you.

sef_: ah, ok, those are both created on the 12th of September, so we would have stopped retrying by now. You would have to just retrieve them from the API to process them. https://stripe.com/docs/api#retrieve_event-id

sef_: if a particular event fails to deliver, we will retry it for about three days with the exponential backoff I mentioned earlier: https://stripe.com/docs/webhooks#responding-to-... If your endpoint is consistently failing to acknowledge events, eventually we will disable the endpoint, which is what the email is referring to.

stherold: hi

stherold: no, it shouldn't matter if you use a token or a source. Sources are a newer abstraction that make it a little easier to handle multiple payment sources.

stherold: you can pass a `source` event callback to the payment request button API : https://stripe.com/docs/stripe-js/reference#pay...

stherold: if you're using the iOS integration instead you can use this : https://stripe.github.io/stripe-ios/docs/Classe...:

stripe968: sorry, I don't understand what you're asking

stripe968: are you using automatic or manual payouts?

stripe968: https://dashboard.stripe.com/test/payouts

stripe968: that test card just makes funds available for payout, it doesn't create the payout. Try retrieving your balance and you'll see that the funds from charging that card are `available`: https://stripe.com/docs/api/#retrieve_balance

stripe968: it depends. The funds are available now. If you're on automatic payouts an automatic payout will be created based on your schedule(https://dashboard.stripe.com/account/p... , probably tomorrow). If you're on manual payouts, you can create a payout now using the API.

stripe968: a manual payout doesn't have sources because there's no way to know which specific charges were involved, since you just say "pay out $x from my balance"

stripe968: so it's not really possible for you to say what charges are in it. Especially since you're using Standard connect — the payout could contain funds that aren't even related to your system and are just from other charges the account made

stripe968: I mentioned this to you yesterday, if it was me I would really just look at `available_on` for the BT associated with each charge you create, and you can tell your users that the funds from their charge is available on that date https://stripe.com/docs/api#balance_history-ava... Beyond that, it's Standard Connect, so the user is controlling their payout experience.

if they use automatic payouts then you can use the `source` approach to know when a particular charge is paid out. But that won't work with manual payouts, that's just how it its.

it is*

stripe968: there's not really any status to monitor here. You call the API to make the charge and it's successful. The funds can be paid out on `available_on`. That's it.

stripe968: that's how I would do it, yes. You can use the approach I described of "list + look at `source` when `payout.created` happens" if you like, but I don't think you need to.

stripe968: remember it's Standard Connect. The user can just log into their own dashboard and see all this information themselves.

Tim__: sure thing! what's up?

Tim__: that sounds more like you want a receipt or a report, not an invoice. An invoice is a demand for payment usually

Tim__: one way you could do this though is create invoice items for each credit the user buys : https://stripe.com/docs/api#invoiceitems Then at some point you can create a new invoice, and it will suck in all the items you've previously created https://stripe.com/docs/api#create_invoice