#GiGStartr

1 messages · Page 1 of 1 (latest)

brazen shell
limpid locust
#

I'll note I'll have to wait a day or two for the actual test payout to occur, and see what THAT generates

brazen shell
#

Looking now - sorry for the wait!

limpid locust
#

np at all - my own build-deploy-test loops are not insubstantial, so it gives me a cocktail break

#

FYI, possible advice for future devs: set up webhook endpoint to handle ALL events; use a "switch" or equivalent to dispatch to handlers, and log events that are NOT handled while still returning "success" - give a LOT of visibility

brazen shell
#

So I can confirm payment.created is a deprecated/undocumented event that you'll get if your webhook endpoint is listening for all event types.

limpid locust
#

(oh, and my webhook endpoints are Google Firebase Cloud Functions)

#

Well, it may be deprecated, but transfers to connected accounts still generate it

#

I guess I'll wait a day or two to see the connected account payout, and see if it generates any events

brazen shell
#

Yeah sorry - deprecated as in we don't expect your integration to need/use it, but it's a known issue on our end that we still generate and send it

#

The current equivalent would be listening for transfer.created on the platform account - since the payment (py_) object being created on the conenct account corresponds to the transfer being created on the platform

limpid locust
#

I had to turn on all events since I still don't know how the "$2 per active connected account plus 0.25% + $0.25 per payout" are going to show up

#

only way I can be sure to see what I need is to catch all. Doesn't break anything; as I mentioned I catch all webhooks, but simply log the unhandled ones

#

Do we even know if such charges occur in test_mode?

lusty zinc
#

heya @limpid locust, jumping in on behalf of @brazen shell who had to step away

limpid locust
#

np!

lusty zinc
#

to clarify, are you trying to figure out how to catch the $2 per active connected account plus 0.25% + $0.25 per payout fee as an event?

limpid locust
#

Because I'm using separate charges & tansfers with transfer_groups, I have to carefully monitor transactions to make sure of available balances. As such, I want to see anything that affects the platform balance

#

I've asked here AND your support team whether and/or where such charges show up, and so far nobody knows

lusty zinc
#

alright, i hope you don't mind, but i'm going to need to ask you a couple of questions to make sure i understand your use case first

limpid locust
#

I gotta few paragraph scenario I've shared a few times if you want...

lusty zinc
#

for separate charges & transfers (SCT), do you know approximately how long later (from the time the payment is created) you are going to create the transfer?

limpid locust
#

from days to months - this is US only, so your documentation says up to two years

#

here:

lusty zinc
#

hmmm, alrighty

limpid locust
#

that don't quite work usefully

#

I may have to para by para paste that

lusty zinc
#

we usually recommend that you use the balance.available event to keep track of your balances

limpid locust
#

doesn't help. I will have HUNDREDS of simultaneous events, each with a separate available balance

#

your available balance is the overall account, not any particular transfer_group

lusty zinc
#

are you using the source_transaction parameter when making a transfer?

limpid locust
#

Each events has one to 200 or more ticket purchases, all to ONE transfer_group

#

source_transaction only applies to ONE payment

#

and NO I don't want to create a nightmare of accounting for my connected account customers by creating hundreds of transfers

#

(not to mention costs)

lusty zinc
#

okay, that makes sense.

limpid locust
#

I have all the transfer_group available_balance code already working, actually

#

it's the out-of-band charges (monthly fee, per-payout fees) that are a concern

#

(also, I have a periodic check to transfer balances as they become available to a transfer group - although due to your reporting, this is likely to be a polled rather than event-driven process)

lusty zinc
#

Now, to answer your question about Connect (and Connect Payout) fees,

Payout fee is a fixed fee per payout to a connected account and is deducted from the platform’s Stripe balance around the first of each month for the entire previous month.

So this is how it would look like in the Dashboard

Dashboard > Payments > All transactions > Filter: Type - Stripe fees >
Connect (YYYY-MM-DD - YYYY-MM-DD): Payout Fee

limpid locust
#

cool. and how does this get to my back-end code?

lusty zinc
#

onesec, let me mention about the other Connect fees too so that it's easy to talk about back-end code after that

#

The connect fee is made up of :

  • A fixed fee per active connected account
  • A fixed percentage of account volume which is the sum of all connected accounts' payouts

You can view these fees the same way as the Payout Fee in the Dashboard

Connect (YYYY-MM-DD - YYYY-MM-DD): Active Account Billing
Connect (YYYY-MM-DD - YYYY-MM-DD): Account Volume Billing

limpid locust
#

so are these both accumulated monthly?

lusty zinc
#

they are all accumulated monthly

limpid locust
#

charged to the platform balance, or the connected account balance?

lusty zinc
#

platform balance

limpid locust
#

And I'm guessing nothing will tie them to specific transfers, so I'll have to make some guesses. the $0.25 will require watching for payout events and counting them; the 0.25% I can keep a running total

#

The point is while all these charges and transfers are passing through, I'll have to also be sure the needed fees remain in balance. I do understand that once fully populated the transient balances would generally be sufficient to cover, but I do not like assuming

lusty zinc
#

both you (platform) and your connected accounts are based in the US right?

#

nvm, that was a silly question, you already mentioned that earlier

limpid locust
#

All USA. International will bring a whole new set of problems - like the 60-day limit on holding fund

#

but I have a huge market US-only, so my only goal for the moment is to not preclude international, not to implement it

#

so will those monthly charges create any webhook events? (my original question)

lusty zinc
#

no they will not create any webhook events

limpid locust
#

THAT is most truly unfortunate

lusty zinc
#

to give you some workarounds...

limpid locust
#

I'm guessing I would be able to pull them up in a sigma report?

lusty zinc
limpid locust
#

(I have Sigma enabled for my test-mode, as was about to start writing the API calss)

lusty zinc
#

i'm not convinced that you need Sigma for this

#

the details can be pulled from the API as well

limpid locust
#

I see I can specify stripe_fee - I assume that will NOT include the fees on the original payment_intents/charges?

lusty zinc
#

it will not include the fees on the original payment_intents/charges

limpid locust
#

(I'm still looking how to identify, and associate them with specific connected accounts)

#

or will they be just bulk aggregated?

lusty zinc
#

it's actually bulk aggregated

limpid locust
#

...and the charges will thus be in the amount?

#

sigh. much unfortunate

#

I'll have to do my own tracking then

lusty zinc
#

pretty much yep, you have to do your own tracking

limpid locust
#

no wonder nobody wanted to answer. It's important to my models and metrics, including possible future commissions, so at least I know. This is precisely why I've been whinging on this for a while

lusty zinc
#

i wanted to also answer your question about available funds

limpid locust
#

sure, although I'm listing charges by transfer_group, expanding the balance_transactions, and reducing the available and pending balances from there. It's not a frequent operation, so the resource cost is relatively low

lusty zinc
#

give me a couple of minutes to put my answer together

#

A couple of suggestions :

  • you would want to either use manual payouts; or if you use automatic payouts, ensure the interval of your payout is longer e.g. monthly, not daily
  • sometimes platforms end up with insufficient funds to transfer to their connected accounts, you would want to use top ups [0] to add funds to your account
  • if you want to buffer against fees/disputes/refunds, you would select the Cover negative balances when adding funds to your account. Funds added to Cover negative balances are "ringfenced". You cannot use these funds to transfer to connected accounts, and these funds will not be automatically paid out (although you can click a button to manually pay them out if required)

[0] https://stripe.com/docs/connect/top-ups

#

manual payouts can be a pain, cause you don't get an itemized payout report

limpid locust
#

I'll be using programmatic "manual" payouts to feed into business systems better; I do NOT want to rely only ANY human somehow guessing a top-up is needed; there will be HUNDREDS of transfers PER DAY( hundreds of venues running daily events)

#

Hence, my own transfers will form my reports

#

the buffering will likely be both combination of top-up cash & Cover negative balances , although if I can automate that as well I will

#

part of our agreement, in current model, is connected accounts get transferred funds AFTER the event occurs (this is so we can make promises to users) as the funds become available (as tickets may be sold from many weeks before up to day-of)

#

we could consider switching to guaranteed payout to event organizers immediately after event is approved, but that WOULD involve us maintaining funds in balance to cover differences. That's a decision for the bean-counters

#

yeah, I chose the most complicated path here, but it's only code. Once I know how the system works (teeny matter of little documentation on the mehcanics of the connected account fees), it's easy.

#

Hm. I assume charges for Sigma and other services will come in the same way - just aggregated charges direct to platform balance with out events?

#

Is there any info you are aware of in the transactions to identify which they are?

lusty zinc
#

it should be in a description field

limpid locust
#

oooo, another parser. fun! I did, btw, just see a payout to a connected account in test mode, so that there's another datapoint.

#

Is there anyplace that lists the different descriptions possible for the various charges?

lusty zinc
#

hrm, unfortunately we don't have a list for this

limpid locust
#

oy. sigh. I hate having to guess on the fly.

#

well, if you hear of anyway to figure out how to anticipate the charge descriptions, I'd love to hear about it.

lusty zinc
#

for the Connect fees which you're interested in, it should be these
Connect (YYYY-MM-DD - YYYY-MM-DD): Active Account Billing
Connect (YYYY-MM-DD - YYYY-MM-DD): Account Volume Billing
Connect (YYYY-MM-DD - YYYY-MM-DD): Payout Fee

limpid locust
#

those help. I'll come back later for Radar charges, Sigma charges, etc etc as needed.

#

you personally seem to have somewhat deeper insight into these things - should I address these specific questions to you, or the discord generally? (I'm not trying to turn you into my personal tech support)

lusty zinc
#

actually Stripe Support really should have been able to answer your questions

limpid locust
#

Multiple weeks of back-and-forth and we'll-get-back-to-you

lusty zinc
#

yeah, i understand that too 😦

limpid locust
#

even simplyknowing the charges are out-of-band helps- I can build my systems around it. I appreciate the effort here.

lusty zinc
#

i think you can try your luck here, the problem is that this particular area which you have questions isn't something which most of the engineers that are helping out here have a lot of knowledge on

limpid locust
#

😀 I got that impression

#

If it makes y'all feel any better, I'm similarly deep in the weeds with the Google Firebase tram and the CodeSandbox tram...

#

er... team...

#

I'm a 40-year developer, so I get very very deep into the weeds very very fast on all projects

lusty zinc
#

by the way, let me just quickly verify again that what i told you about the description is correct

#

i wanna double/triple check

limpid locust
#

Sure, I can hang out a few minutes more

lusty zinc
#

so the below is not a Connect fee, but it's more to give you an idea of how the description will look like

{
      "id": "txn_0I9dlQ589O3K5xCGU30HCi9z",
      "object": "balance_transaction",
      "amount": -29,
      "available_on": 1610661236,
      "created": 1610661236,
      "currency": "usd",
      "description": "Card payments (2021-01-12): Stripe volume fees",
      "exchange_rate": null,
      "fee": 0,
      "fee_details": [

      ],
      "net": -29,
      "reporting_category": "fee",
      "source": null,
      "status": "available",
      "type": "stripe_fee"
    },
#

and yes, it the description will show when you retrieve the balance transaction

#

Hope you have a good rest of the day!

limpid locust
#

thx. Alas, human-readable descriptions may be a tad more complex to parse, but we'll get there. Feel free to archive the thread.