sricar09_docs

[agile pawn]

👋 Welcome to your new thread!

⏲️ We'll be here soon! Typically we respond in a few minutes, but sometimes we might take a bit longer if the server is busy or if you have a particularly tricky question.

⏱️ We close idle threads, which makes them read-only. Once a thread is closed it won't be reopened, but you can always start a new thread if you have another question.

🔗 This thread will always be available, even after it's closed. You can find it again using Discord's search, or you can save this link: https://discord.com/channels/841573134531821608/1408544908410884246

📝 Have more to share? Add more details, code, screenshots, videos, etc. below.

[tacit robin]

• For a US platform account, we aren’t able to edit our onboarding configuration settings to setup the bacs_direct_payments capability automatically for UK connected accounts. We need to request this through the API
• On the platform account Connect payment method settings, it is safe to enable bacs direct debit for all UK connected accounts. This won’t cause a delay in payouts for any connected accounts.
  • Even for existing connected accounts, no additional information that may delay payouts is requested from them until the bacs_debit_payments capability is added to their connected account.
  • For newly created connected accounts, they won’t receive the bacs_debit_payments capability until we request it during the onboarding/oauth process or with an account update.
  • The above applies for all connected account types, including standard and custom, as well.
  • When using the API to modify this, in order not to accidentally remove any capabilities, I should retrieve the list of capabilities on the Account first, before calling Stripe::Account.update , since the list of capabilities provided in the request is not additive; it overwrites the existing list of requested capabilities. Alternatively, I can use Stripe::Account.retrieve_capability and Stripe::Account.update_capability to update one capability at a time
• When a bacs_debit_payments capability is removed from a connected account:
  • All mandates become invalid and any future payment attempts will fail. mandate.updated events are sent with the status changed to inactive
  • Subscriptions will fail at the time of the next charge and after multiple failed charges will cancel. They aren’t cancelled automatically.
  • Any pending payment intents for charges will generate a charge.failed event at the time of processing, or potentially at the time the mandate is deemed invalid.

[maiden thunder]

"For a US platform account, we aren’t able to edit our onboarding configuration settings to setup the bacs_direct_payments capability automatically for UK connected accounts. We need to request this through the API"

How are you creating the connected accounts?

[tacit robin]

We're currently using legacy oauth express flow (https://docs.stripe.com/connect/oauth-express-accounts), we're planning to migrate off of that after this.

[maiden thunder]

Gotcha, then yes, you'll need to request the capability for the connected accounts via the API.

[tacit robin]

Awesome thank you!

Is the other information about webhook event and endpoints ok?

[maiden thunder]

On the platform account Connect payment method settings, it is safe to enable bacs direct debit for all UK connected accounts. This won’t cause a delay in payouts for any connected accounts.

Yes, you can enable BACS for all UK Connected Accounts. It should not impact Payouts.

Even for existing connected accounts, no additional information that may delay payouts is requested from them until the bacs_debit_payments capability is added to their connected account.

Ok

For newly created connected accounts, they won’t receive the bacs_debit_payments capability until we request it during the onboarding/oauth process or with an account update.

Ok

The above applies for all connected account types, including standard and custom, as well.

This makes sense.

When using the API to modify this, in order not to accidentally remove any capabilities, I should retrieve the list of capabilities on the Account first, before calling Stripe::Account.update , since the list of capabilities provided in the request is not additive; it overwrites the existing list of requested capabilities. Alternatively, I can use Stripe::Account.retrieve_capability and Stripe::Account.update_capability to update one capability at a time

Have you tested this? Capabilites are additive. Existing capabilities are not overwritten when you update the account via the API. I just tested this on my end.

[tacit robin]

Oh ok! I haven't had an opportunity to try it yet, I will make sure to test that out

[maiden thunder]

When a bacs_debit_payments capability is removed from a connected account:
All mandates become invalid and any future payment attempts will fail. mandate.updated events are sent with the status changed to inactive

If the Bacs capability is removed from a connected account, the existing mandates could become invalid because the account would no longer have the capability to process the direct debits.

Subscriptions will fail at the time of the next charge and after multiple failed charges will cancel. They aren’t cancelled automatically.
Any pending payment intents for charges will generate a charge.failed event at the time of processing, or potentially at the time the mandate is deemed invalid.

Yes the Charge will fail if the subscription is set to charge_automatically. Our doc on billing collection methods goes into more details about subscription behavior in these scenarios [0].

[0] https://docs.stripe.com/billing/collection-method#set-collection-method-subscription