#stripe

Does anyone have advice on building a payments transactional database and tracking refunds so that we can pull the available amount to refund data and display it to a customer service person handling refunds via the UI?

Meld052015: advice in what sense?

it's sort of an open-ended question

Hi, I've got a Stripe question...

I've got a connected User who also has their own Stripe account

Gyromaniacs: sure

I'm using stand alone accounts

Is there any way on their Statement I can distinguish my charge from their existing Stripe account?

I should say, they have two different Stripe accounts actually

One for their retail store and one for their Online Store

When charges happen and Stripe deposits money in their bank, is it possible for them to distinguish between the two deposits so they know which is which?

essentially, no

both will just have the descriptor STRIPE TRANSFER

PREAUTHORIZED CREDIT STRIPE TRANSFER X CCD

Is what it says

the 'X CCD' is that a distinguishing mark?

Or is there any other way to distinguish which is from the Online Store and Which is from the Retail Store?

ccd is just the type of deposit

they'd need to reconcile the transfers by the date of the transfer and the amount of the transfer against what's displayed in stripe

That's what I told them, but they said they want it on their bank statement

Should I tell them just to move to manual transfers instead?

Gyromaniacs: they could do that, yes

hey, is anyone around today?

in which case, they can specify whatever transfer descriptor they want, which would show up on their statement

Any other options you can think of <tr12>?

Gyromaniacs: they'd need to manually send themselves transfers, though, which is a lot of toil, or else write / have you write a script to automatically send the transfers

no, I don't believe there are any other options here

patr: what's up?

do i need to create a token to get subscriptions from a stripe connected account?

and then pass the token into the

stripe.Subscription.retrieve()

call?

documentation on this is a little light

patr: a token as in the ID of the subscription?

uhh no

as in the connected account ID

when I create a charge, I need to do this

token = stripe.Token.create( customer=customer.stripe_id, stripe_account=connected_account.stripe_user_id # id of the connected account )

oops

yes - this identifies which connected account you want to operate on

how do I pass that token into the retrieve call?

you'd just set stripe_account=... in the retrieve call

the syntax for this is the same for every api call

the API docs shows this

stripe.Subscription.retrieve("sub_8XlIYBNZk4a7Lj")

so just that token is enough?

the api call works the same on your platform account as on the connected account - the only difference is that the stripe_account identifies which account you mean

i don't have to set stripe_account?

if you just pass an ID, it assumes you're talking about the platform account

stripe.Subscription.retrieve("sub_8XlIYBNZk4a7Lj", stripe_account=blah)

so it'll look for that subscription on the platform account, and won't find it if it's actually on the connected account

yes, that looks correct

tr12. Do you have any good resources, in addition to the Stripe docs on building a payments transactional db and how to track the different states of a payment? I think this is a basic question but could use your help

Meld052015: I don't really know what you're asking, though

again, the question is too general

tr12: token = stripe.Token.create(customer=customer.id, stripe_account=stripe_account.id), stripe.Subscription.create(token=token)

is this a proper way to create a subscription

(similar to a charge)

Meld052015: as far as tracking the states of a payment, card payments only really have 2 state transitions that can happen - refunds & disputes

<tr12> anything special you have to do to indicate on a manual transfer?

Meld052015: you can listen to webhooks to be notified of events (including disputes). it's also useful to listen to webhooks for refunds that weren't done by your own code (ie: were done by through the dashboard)

patr: you need to tell it what plan to use, and you'd need to pass stripe_account to the subscription create call

Thank you, I’ll think about this some more. Thanks tr12

patr: otherwise it's going to run the call on your platform account, and not find the token

ah

the source isn't enough?

patr: separately, the parameter is called `source`, and not `token`

err sorry i meant source

and yes, you need to tell it what *kind* of subscription to make

you need to specify a `plan`

ah yeah i forgot the plan

you also need to create a customer

yeah customer is pre-created

on my platform

so that's why i use the token to link it to the connected account

no, you need to create a customer on the connected account for that subscription to be attached to

<tr12> Where can you specify on manual transfers how to display a different bank statement descriptor?

patr: so like stripe.Customer.create(source=..., plan=..., stripe_account=...)

oh

I've found the switch to manual transfers

Gyromaniacs: https://stripe.com/docs/api#create_transfer-sta...

so this token = stripe.Token.create(customer=customer.id, stripe_account=stripe_account.id)

and then linking to the source

isn't enough?

i can create charges that way

Gyromaniacs: when you create a manual transfer, you can pass a `statement_descriptor`

patr: those charges aren't attached to a customer on the connected account

they're just made against a one-off token

ah

(and that token happens to be created from a customer on the platform account, but that's not important)

so i'll have to create a customer for each individual connected account

if they want a subscription too

subscriptions need to be created on a customer, and that customer needs to exist on the connected account

<tr12> Making a manual transfer through the API turns them into a managed account does it not?

yes

Gyromaniacs: no

Gyromaniacs: the difference is that you can't change the transfer schedule of a standalone account

if they *want* to be on manual transfers, they can put themselves on manual transfers

Ok - So if they keep their transfers as Automatic it will keep saying STRIPE

Gyromaniacs: but you can't do this on their behalf

correct

Even if I pass on the statement descriptor

If they switch to manual transfers it will use the statement descriptor I have set for them?

if they're not on manual transfers, you can't create the transfer, which is where you'd be passing that statement descriptor

so there's nowhere for you to pass a custom statement descriptor

Ok - Where do they set their own statement descriptor if I can't pass it on?

Gyromaniacs: they can't - if they're on automatic transfers, the statement descriptor is always STRIPE TRANSFER

Ok - Say they turn their account to MANUAL

they'd need to put themselves on manual transfers, then create transfers themselves

and when they create each transfer, they'd pass a statement descriptor

Will that require coding on their part or is that part of the Stripe Dashboard?

I've never used the feature myself yet...

Gyromaniacs: they can do this manually, but it's going to be very tedious

because they'd need to manually initiate every transfer

like, a human would need to do this through the dashboard

It's them that is requesting this visibility so they will have to deal with the pain

you/they'd almost certainly want to automate this - listen to the balance.available webhook & create a transfer for whatever's available

fair enough

tr12: are you sure I *must* create a customer on the connected account?

looking at these docs it says I can pass in a source parameter

very sure

and that source parameter can be a one off token

that also says "customer: required"

those docs list customer as a required parameter

jinx

(sorry was just looking at that exact question from someone else)

oh

should i in my backend

keep the customer id?

gonna get confusing

is there a way to link a customer on my platform to the customer in the connected account?

or do i have to create that link on my side?

no - they're on different accounts

it very likely makes sense to hold onto both the customer & subscription id

(ie: the customer id of the customer on the connected account)

yeah

man that's a headache

if that user has multiple subscriptions on that connected account over their lifetime, you don't really want to be spinning up a customer for each one

yeah

^ which is really just an organizational thing, to be clear

yeah i know

organizational headache ha

it doesn't cost extra, or make extra auths, or something is what I mean