#Kamon-connect

1 messages · Page 1 of 1 (latest)

brave zincBOT
midnight socket
#

Hey there

#

Yep so we highly recommend that you don't use destination with Standard Connect

#

The main reasons involve the Connected Account experience here

#

With Standard, the Connected Account has full control of their Dashboard

#

So they can go in and issue things like refunds

#

However, with destination charges, you are controlling everything from your platform account.

#

So for instance a Standard Connected Account user could go in and issue a refund thinking they are refunding their customer, but really they just sent funds back to your platform (all they did was reverse the transfer involved in the destination charge) .

#

Furthermore, it is much harder to have strong reporting with Standard + destination as there are some rough edges there since Reports really weren't designed for this flow

edgy grotto
#

Woah, thanks for such a quick reply, you're on it :D!

Interesting. So it seems more-so the charge type itself dictates whom is responsible for disputes, chargebacks, refunds, etc, rather than the account type? Furthermore, does that mean that really the only thing that account type has bearing on is what the user experience for the connected account is?

midnight socket
#

Overall yes, but a major thing the account-type dictates is the UI that your user interacts with.

#

Standard = full Dashboard experience, Express = partial Dashboard
Custom = you create the Dashboard

edgy grotto
#

Gotcha!

If I was to go against the grain and use Standard Accounts with Destination charges, whom is responsible for disputes, chargebacks, fraud, etc? The platform or the connected account?

midnight socket
#

You as the platform

edgy grotto
#

Sorry if it seems like I'm repeating questions, I want to make sure that I'm as informed as possible. I really appreciate the help and insight.

Are there any exceptions or outliers to this rule (no matter what account is used).

Destination Charges - Platform is responsible for operational procedures (charges, fraud, refunds, disputes etc).

Direct Charges - Connected account is responsible for operational procedures

Also, where does separate charges and transfers fall here for responsibility?

midnight socket
#

Np at all, we are here to help

#

So with Standard + Direct you have flexibility in that the platform can handle those operational procedures if you so desire but so can the Connected Account. So for instance you could still issue refunds if you want on a Standard Connected Account. However, the Connected Account will be able to do this too.

#

With Destination the Platform is always responsible for all of this.

#

Same with Separate Charges & Transfers since the Charges will all occur on your platform account.

#

That is the biggest thing — understanding where the Charge actually occurs (what account) and then who can action that Charge

edgy grotto
#

That makes sense.

If we initiate a refund for a customer that was a direct charge on a standard connected account and the connected account doesn't have available funds, what happens?

midnight socket
#

Their balance goes negative and after a certain point refunds are held in pending

edgy grotto
#

The customer does not receive a refund until the connected account has enough funds to process that refund, correct?

midnight socket
#

If they surpass the negative balance threshold and their refunds are held in pending then yep, the refunds aren't sent until their negative balance is repaired.

edgy grotto
#

Gotcha, so from a customer service perspective, if we have a customer whom is asking for a refund for a connected account that is MIA or never going to become positive again, how would that be handled?

midnight socket
#

We attempt to debit their attached bank account

#

If that fails, then it is either on you as the platform to repair the negative balance, or with Standard Accounts that Connected Account is liable for those funds

edgy grotto
#

So, to repair that negative balance, we'd transfer funds to the connected account, to ultimately have the customer's refund process, rather than send money to the customer?

midnight socket
#

Yes

#

Or you could wait for further payments to that Connected Account for the balance to be repaired

edgy grotto
#

Gotcha, that makes sense.

What features, best practices or flows are missing from the Connect Rides demo?
It seems incredibly simple to integrate Express and even Standard connect accounts, but I feel like I'm missing something.

#

I've tested integrating it with our platform and it's pretty straight forward, but would love any insight here.

midnight socket
#

That is really up to you

#

There are no "features missing", like it works end to end.

#

And yes it should be easy to integrate at a base-line

#

But you likely will want to implement more fraud protection and stuff like that to make sure your platform is secure

edgy grotto
#

Can you elaborate on the fraud protection a bit more? I though that Stripe handles that?

midnight socket
#

We handle a lot of it sure, but you likely want to protect against things like card testing (https://stripe.com/docs/disputes/prevention/card-testing) and you may want to put further protections in place so you don't onboard fraudulent users (especially if you are using Express or Custom accounts as then you are ultimately liable for whatever happens with those accounts).

#

It is mostly up to you

#

The Rocket Rides example is indeed "complete"

#

And yes overall this stuff should be easy to integrate! That is certainly our goal!

edgy grotto
#

Thanks for that info!

Is it okay if I keep asking questions?

#

Don't want to overwhelm you, 😂

midnight socket
#

My team is here 24/5 to answer questions 🙂

#

I will need to step away shortly but my teammate is going to take over.

#

As long as they are questions about our API we are happy to help

#

Otherwise we will let you know if you need to reach out to our Support team

#

So keep asking any questions you have!

edgy grotto
#

Kick ass, thank you. Y'all rock!

In the event that we use Standard accounts, what's the best way to update the status of orders (i.e in dispute, refunded, etc) if connected accounts refund from within the Stripe dashboard. Web hooks?

midnight socket
#

Yep

#

You want a Connect Webhook endpoint no matter what type of Connected Accounts you use

vapid agate
#

Kamon-connect

edgy grotto
#

Gotcha, thanks!

Can y'all elaborate a bit on in your honest opinion, what are the primary reasons to use an Express Account over Standard and vice-versa?

The platform fees are a bit on the steep end for Express, and it seems like the primary benefits are the fact you can cleanly use destination/SCT charges and you get a pared down dashboard.
But, the platform is then responsible for essentially all operational transactions.

It's almost like you're losing functionality and being charged more just to use destination charges.

Sorry, definitely not trying to be rude, but I'm genuinely curious, especially as a platform that the pared down functionality of Express and the supported charge types are appealing, but the fees make our pricing model difficult.

A couple other questions:

  1. If we are a scheduling service and hold funds and authorizing payment intents potentially days/weeks after the initial order is made, would we have to use SCT charges to handle this use case?

  2. How does Tax Reporting work for Express and Standard accounts?

#
  1. Similarly to #1, if we hold funds until a payout threshold is met (to help offset Express account costs), we'd have to use SCT charges, correct?
#

Also, howdy @vapid agate, thanks for taking over and continuing to deal with me 😂

#

This is seriously a huge help.

vapid agate
#

Always happy to help! The key difference between them is the experience they allow you to build. Using Standard Accounts is a better fit if your connected accounts represent more independent entities. When using Standard+Direct charges, it is more apparent that your customers are interacting directly with your Connected Accounts. When using Express+Destination, the customer is interacting with you the Platform rather than directly interacting with our connected accounts.

#

For 1, can you elaborate? Are you referring to holding funds in your Platform account balance for a period of time before transferring them to your Connected Accounts? If so, then yes Separate Charges and Transfers is the right approach.

vapid agate
edgy grotto
#

Thanks for the clarification there.

  1. For some transactions (that are scheduled 7+ days out), we don't authorize a paymentintent until it's within that 7 day window (to match with Stripe's auth window). After an order's requirements are filled, we then capture the payment on our account and also allow for a refund window for customers. Once we move to handling payouts, we're trying to determine if we'll need to hold funds in our account during that refund window.

  2. I guess I'm more-so curious if tax reporting to connected accounts differs for any of the account types? It's not entirely clear to me.

  3. This would be in Scenarios where we want to meet a minimum threshold before initiating a payout/transfer to make sure we're covering Stripe Connect fees (i.e if a user only has one $1 order during the month. If we transferred that $1 less platform fees to their account, it'd be a net less on our end as Stripe would mark that account as active and charge us $2 + fees for that payout).

So, we'd hold funds in our platform account until they've met a threshold and then we'd initiate a transfer/payout to them.

vapid agate
#
  1. For some transactions (that are scheduled 7+ days out), we don't authorize a paymentintent until it's within that 7 day window (to match with Stripe's auth window). After an order's requirements are filled, we then capture the payment on our account and also allow for a refund window for customers. Once we move to handling payouts, we're trying to determine if we'll need to hold funds in our account during that refund window.
    Gotcha, this sounds like a decision for you to make based on the flow you're trying to accomplish, but if you do need to hold funds on your Platform then Separate Charges and Transfers is the way to go.

Also important when discussing manual payouts, there are limitations on how long those funds can be held before we will trigger a Payout based on the location of the Connected Account, shown in the table here:
https://stripe.com/docs/connect/manual-payouts

#
  1. I guess I'm more-so curious if tax reporting to connected accounts differs for any of the account types? It's not entirely clear to me.
    I believe so.

This doc indicates that Standard Accounts have a 1099-K generated, whereas it seems you have more control over what forms to generate for Express/Custom Accounts.
https://stripe.com/docs/connect/tax-reporting
(this is assuming you're talking about US tax reporting)

edgy grotto
#

Thanks!

For Express accounts, does stripe contact connected accounts for user account issues (i.e for more identify verification docs)?

#

I noticed that on the list for best use cases for standard accounts, but not Express, so want some clarification.

#

Also, are there any other events that a platform would need to handle user account issues when using Express that Stripe would handle with a Standard account?

vapid agate
# edgy grotto Thanks! For Express accounts, does stripe contact connected accounts for user a...

For some matters, yes, but your Platform will likely want to also keep track of which of your Connected Accounts are fully onboarded, so you don't try to process a payment for an account that can't yet receive Transfers.

If you detect the account is missing information (checking charges_enabled, payouts_enabled, capabilities, and requirements fields on the Account object) then you'll provide ways for them to provide those missing details by generating another Account Link for them.
https://stripe.com/docs/connect/express-accounts#handle-users-not-completed-onboarding

edgy grotto
#

How do those fields on the account differ from details_submitted?

vapid agate
#

Significantly, details_submitted is a boolean that doesn't provide any level of granularity the way the other fields I referenced do.

You can see all fields on the Account object, their description, and their contents here in our API reference:
https://stripe.com/docs/api/accounts/object#account_object

edgy grotto
#

So details_submitted is a catch-all for all of those other fields? Is it safe to assume an account has done all necessary steps to receive payouts? The docs don't specify what this field really means, especially for Express accounts.

When creating an account link, do these more granular fields allow us to request the user to specify which information still needs to be filled out or does Stripe figure that out and give notifications/alerts when they reach the dashboard?

vapid agate
#

I do not know if notifications are thrown in Express dashboard (Express accounts do not have access to the full Stripe dashboard the way Standard accounts do), we in this forum focus on the API side of things and aren't as knowledgable on dashboard features. Our Support team may be more familiar with what functionality is provided by the various dashboards.
https://support.stripe.com/?contact=true

#

payouts_enabled is the better field to reference to see if an Account is ready to receive Payouts

edgy grotto
#

Fantastic! I think that's all of the questions I needed answered for now. Again, I really appreciate all of the help y'all have given me. I'm incredibly impressed, this is by far the best developer support I've received in a very long time. I've used Stripe Payments before and didn't even realize this was a resource, it's a huge boon for developers.

Is it best add any future additional questions I have here, or should I ask again in #dev-help and have a new thread be started by y'all?