#GiGStartr
1 messages · Page 1 of 1 (latest)
I'll note I'll have to wait a day or two for the actual test payout to occur, and see what THAT generates
Looking now - sorry for the wait!
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
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.
(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
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
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?
heya @limpid locust, jumping in on behalf of @brazen shell who had to step away
np!
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?
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
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
I gotta few paragraph scenario I've shared a few times if you want...
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?
from days to months - this is US only, so your documentation says up to two years
here:
hmmm, alrighty
we usually recommend that you use the balance.available event to keep track of your balances
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
are you using the source_transaction parameter when making a transfer?
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)
okay, that makes sense.
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)
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
cool. and how does this get to my back-end code?
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
so are these both accumulated monthly?
they are all accumulated monthly
charged to the platform balance, or the connected account balance?
platform balance
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
both you (platform) and your connected accounts are based in the US right?
nvm, that was a silly question, you already mentioned that earlier
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)
no they will not create any webhook events
THAT is most truly unfortunate
to give you some workarounds...
I'm guessing I would be able to pull them up in a sigma report?
you could pull them up in a sigma report, or you can list the relevant balance_transactions : https://stripe.com/docs/api/balance_transactions/list#balance_transaction_list-type
(I have Sigma enabled for my test-mode, as was about to start writing the API calss)
i'm not convinced that you need Sigma for this
the details can be pulled from the API as well
I see I can specify stripe_fee - I assume that will NOT include the fees on the original payment_intents/charges?
it will not include the fees on the original payment_intents/charges
(I'm still looking how to identify, and associate them with specific connected accounts)
or will they be just bulk aggregated?
it's actually bulk aggregated
...and the charges will thus be in the amount?
sigh. much unfortunate
I'll have to do my own tracking then
pretty much yep, you have to do your own tracking
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
i wanted to also answer your question about available funds
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
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 balanceswhen adding funds to your account. Funds added toCover negative balancesare "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)
manual payouts can be a pain, cause you don't get an itemized payout report
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?
it should be in a description field
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?
hrm, unfortunately we don't have a list for this
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.
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
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)
actually Stripe Support really should have been able to answer your questions
Multiple weeks of back-and-forth and we'll-get-back-to-you
yeah, i understand that too 😦
even simplyknowing the charges are out-of-band helps- I can build my systems around it. I appreciate the effort here.
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
😀 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
by the way, let me just quickly verify again that what i told you about the description is correct
i wanna double/triple check
Sure, I can hang out a few minutes more
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!
thx. Alas, human-readable descriptions may be a tad more complex to parse, but we'll get there. Feel free to archive the thread.