#kamon-account-payoutsenabled

1 messages · Page 1 of 1 (latest)

pure reefBOT
tardy dune
#

kamon-account-payoutsenabled

#

details_submitted should not switch to false, but also you should ~never need that property
payouts_enabled can definitely switch to false, for many reasons. That one is 100% something you need to handle as a platform, same for charges_enabled

bitter nova
#

Interesting, why do the docs suggest in a few areas to check for details_submitted to confirm a user is ready for payouts?

Can you go into a few instances that would cause payouts_enabled to switch to false for Express connect accounts?

#

We're currently looking to use Express + SCT Charges to handle payouts, could you also elaborate other things we should look out for/handle? The docs are fairly light for anything other than super basic onboarding.

tardy dune
#

Mostly there's no reason to look at details_submitted. But really it's really common for an account to have to provide more details over time and that would disable their payouts (and later charges) if they don't provide the information in time

#

we (Stripe) could also reject that account

bitter nova
#

Interesting. I read through that, but it seems like it largely pertains to Custom accounts, not Express.

#

I know the lines are blurred a bit between the two, so does the information also pertain to Express accounts?

tardy dune
#

yeah it works the same. Just with Express you don't have access to the PII (like the identity of the people). but overall the concept of requirements, charges_enabled and payouts_enabled are similar

bitter nova
#

Gotcha, thanks! What information is generally required from a connected account user for SCT charge payouts/transfers?

#

(for Express)

tardy dune
bitter nova
#

That's perfect, thank you!

Off the top of your heard, other than what's listed below, is there anything you think should be handled for Express Accounts + SCT Charges? Trying to get to the bottom of everything that's going to be needed for our integration. We'll eventually be handling US->International transfers, too, if that makes a difference.

  • Creating Initial Account and Account Link
  • Return From Stripe URL (return_url and refresh_url) handling
  • Confirmation that payouts are enabled (and webhooks to handle those changes)
  • Account Link Creation to collect additional information to maintain payouts_enabled status
  • Account Login Creation for Express Users to Access their Dashboard
  • Actual Transfers for SCT Charges (Will most likely be for multiple charges after a $ threshold has been met)
  • Service Agreement Collection for International Connect Accounts

Brb, need to hop on a call, take however much time you need to respond!

#

I'd also be interested in any complete open-source Stripe payout integration examples, if you know of any. The only ones I've found are the ones from Stripe (i.e Rocket Rides), but I'm hoping to find something more real world and comprehensive, if you know of any!

tardy dune
#

that seems fine overall and makes sense

#

I'd recommend talking to our support team more than us for this though

bitter nova
#

I'm back! I've been working with the support team, but they keep pointing me over here for my questions, haha.

Do you have time to answer a few more questions?

hardy quiver
#

sure, we'd be happy to help. We mainly answer API related questions so if the questions start to veer off into other areas, we may have to redirect you back to support who has more expertise on those areas though

bitter nova
#

No problem at all, totally understand there, just appreciate the help!

#

Here are a few more questions:

  1. For Destination Charges, is there a way to create PaymentIntents without a connected account associated with it (or is this just basically a separate charge and transfer)?
  2. Can we update PaymentIntents for either transfer amount or the connected Stripe account? If it can be updated, what instances can it not (i.e if the payment has already been authorized).
  3. With Destination Charges, at what point is the money transferred to the connected account's Stripe balance and at what point is the money transferred from their Stripe balance to their payout account (bank/debit).
  4. For SCT charges, are there any limitations for holding funds for a period of time (or potentially indefinitely), before transferring them to the connected account?
  5. For SCT charges, is there even a need to use transfer_group when creating PaymentIntents, or is it primarily a nice to have?
hardy quiver
#
  1. For Destination Charges, is there a way to create PaymentIntents without a connected account associated with it (or is this just basically a separate charge and transfer)?

No, for a Destination Charge, you must include the connected account in transfer_data[destination] : https://stripe.com/docs/connect/destination-charges

#
  1. Can we update PaymentIntents for either transfer amount or the connected Stripe account? If it can be updated, what instances can it not (i.e if the payment has already been authorized).

I assume you're referring to a Destination Charge - like you mentioned, when the payment is already successful (a.k.a authorized), then you cannot update the transfer amount or the connected Stripe account.

#
  1. With Destination Charges, at what point is the money transferred to the connected account's Stripe balance and at what point is the money transferred from their Stripe balance to their payout account (bank/debit).

The Transfer object is created once the payment (a.k.a PaymentIntent) is successful. The Transfer object exists on your Platform account, it results in a Charge object (starting with py_ in it's id) on the connected account.

To know when the funds in the Charge object becomes available to be paid out, you can check the available_on parameter in the corresponding BalanceTransaction object : https://stripe.com/docs/api/balance_transactions/object#balance_transaction_object-available_on

#

when the money is paid out depends on when the funds becomes available and what is the payout schedule of the connected account (e.g. daily? weekly? etc).

#
  1. For SCT charges, is there even a need to use transfer_group when creating PaymentIntents, or is it primarily a nice to have?

transfer_group is a nice to have. you can think of it as labelling / tagging to make it easier to identify associated objects

bitter nova
#

Absolutely wonderful answers, thank you!

Elaborating on #4, our platform is thinking of having the following User/Payout flow (Express Accounts + SCT Charges):

User creates an account with our platform -> They can start using our platform to start accepting transactions -> Once they're ready for a payout or after us nudging them, they begin the Stripe onboarding process -> They complete onboarding -> They can start accepting payout(s).

We want to limit friction when creating accounts and while we'll likely trying to encourage them to go through the Stripe on boarding process, it won't be mandatory until they want a payout.

Because of this, we'll likely need to be holding funds, potentially even without them having an associated connect account.

In these events, what happens with the money that we've accepted on their behalf if it goes over the holding period threshold?

hardy quiver
#

this is something which you'll need to check in with support i'm afraid 😅

bitter nova
#

No worries if you don't have any insight or anything to add, but always love more feedback!

hardy quiver
#

same as koopajah, it looks alright to me

#

you'll probably have more questions when you actually start implementing it

bitter nova
#

Kick ass, thank you!

I've begun the basics of implementation, but wanted to have a clearer idea of the requirements before pressing very far. Y'all nailed answering my questions, though.

Really appreciate all of the help, thank you!