#sailesh-charge-transfer

1 messages · Page 1 of 1 (latest)

grizzled stone
#

Hey @wicked fern. The problem is that you have too many charges with the same transfer group so we can't filter those charges at all

wicked fern
#

Hmm how am I supposed to go through the list then? I thoguht that's what the pagination was for?

#

Essentially my setup is I have classes that are transfer groups, so that I can make transfers to teachers only after the class is done (instead of having students pay teachers directly)

#

And this class in particular had 213 students pay for it

grizzled stone
#

unfortunately you just can't. We don't support this at all. If you have more than 100 charges with the same transfer_group then you have to list/filter those yourself

wicked fern
#

What do you mean list/filter them myself?

grizzled stone
wicked fern
#

Hmm interesting, that would work for now but eventually we could have hundreds of thousands of charges

#

That's interesting - would request to add that limit for transfer_groups to the docs, we'll find a different solution for now...ty!

#

Would also add this as a feature request if possible!

grizzled stone
#

yeah basically almost no integration ever does what you do

#

that error message has been here for many years and it's really rarely hit so we haven't prioritized improvements to it

wicked fern
#

Hmm maybe my setup is incorrect then?

grizzled stone
#

OOC why don't you use the "normal" destination charges flow?

wicked fern
#

So to clarify and make sure I'm thinking of this correctly:

  1. Teachers create classes in the future
  2. Students pay for classes before the class happens, and then attend all the sessions
  3. Teachers get paid after the class is completed
#

When we did normal destination charges, it seemed that teachers were either getting paid immediately or after some arbitrary delay, not one that could be dynamic

#

similar to how an airbnb host doesnt get paid until after the stay is complete, but the client might have booked the airbnb months in advance

dry path
#

I'll pop-up here and suggest the same expansion - my business structure is SPECIFICALLY charge & transfer, SPECIFICALLY for events with 1 to 300+ attendees, and was INTENDING to use the list charges via transfer_group in the case of EVENT REFUNDS

wicked fern
#

...but in this case 100s of people could book the same airbnb

dry path
#

I have all the ticket information, and the associated payment_intents, but then it turns into a LOT of individual API calls, rather than one (possibly paginated) call

#

(i.e. it strikes me this request is GOOD for your endpoint loads)

grizzled stone
#

lol all those caps

dry path
#

I kinda write the way I talk...

grizzled stone
#

But yeah other than that you have to do what I recommended which is what @dry path does too. Definitely agree it's a fairly arbitrary limitation. We picked 100 as a limit to start in 2017 and then it's barely been hit and it hasn't blocked many integrations so we never looked into changing this

#

ultimately, when you have a lot of volume, you're better off caching most of this in your own database, that's what I'd do at least

dry path
#

whelp, from Stripe's perspective, me hitting my database for the list of charges/payment_intents doesn't change the endpoint load much since in my case I still have to issue individual refunds...

wicked fern
#

Don't connected accounts initiate their own manual payouts?

dry path
#

(honestly, I thought I was being clever using the charges.list since it can be filtered by transfer_group. ah well)

grizzled stone
#

@wicked fern no, Express and Custom accounts have no control over this, you as the platform control when they get paid out

#

@dry path yeah a mass refund API is not in the cards, especially as it's also an edge-case but I can see how that doesn't really help you much

dry path
#

(now to re-write a big chunk of code)

wicked fern
#

What does "You will have to manually pay out the account’s balance using the Payouts API (acting as the connected account)." acting as the connected account mean?

grizzled stone
#

it's in the doc I shared it has all the info

wicked fern
#

Heh that's where I got the quote from

#

Just want to make sure the teachers aren't able to access their funds or change their payout schedule or anything like that...

"Express and Custom accounts support editing this property."

And then "acting as the connected account" are a little confusing so I would love to clarify

grizzled stone
wicked fern
#

Ahhh ok

#

Perfect i think thats the setup i need then

#

Thank you!

dry path
#

This here is why I lurk on this discord - others ask about issues I haven't hit yet. my current approach (charges.list({transfer_group:"xxxx"}) "worked" in test - but only because I haven't built a test event that had more then 100 charges yet...

grizzled stone
#

yeah, this is one that we're not really happy about since you can't easily detect it, but it's a lot harder to fix than it seems and it's hit so rarely...

#

And I totally hear about lurking on Discord, I'd do the same if I didn't work at Stripe. That's also why I work here, I used to join IRC channels for whatever technology I used and so when I could have a job helping people I jumped on it 🙂

#

But I'll raise the feedback since you both are blocked by this and more examples are always good1

dry path
#

@grizzled stone I'll investigate the "costs"of my alternative. My data is in Firebase Firestore, so I encounter some (pretty minimal) costs in fetching the relevant records, as well as processing the information out of them - the charges.list call was "free", and I could use the resulting object almost directly. But it's all in server/webhook endpoints (Firebase Cloud Functions) so no user impact, but some (again mostly minimal) processing charges. As I said, the actual refund calls are individual, and I already have a rate-limiter built-in (for other reasons). one call-and-reduce for Firestore vs one call to Strip - not sure it'll be a real impact. But very good to know, and impossible to anticipate.

#

Would it be "easier" to add the ability to list/filter the payment_intents by transfer_group?

#

(i.e. from your internal perspective)

#

and/or the quite-soon-to-come-out-of-beta search API?

grizzled stone
#

the search API would be the right path I think, that one can scale. Everything else requires a pretty big rework

dry path
#

(probably going to become a non-issue as I totally change the way I'm tracking transfers, available balances and platform payouts) - does the stripe.transfers.list({"transfer_group": "xxxx"}) suffer the same undocumented limitation?

grizzled stone
#

yes

dry path
#

(I'm also not likely to run into it-I may sell 100's of tickets, but won't transfer that many times)

#

so pretty much all the stripe.whichever.list() endpoints?

#

[at least filtered]

grizzled stone
#

well it's only those 2 APIs that have the transfer_group and it's limited to just that specific filter

dry path
#

hah! that explains why it's always felt kinda after-thought!