Stripe Connect: disconnecting a connected account from the app’s side

[Vladimir Andrijevik]

Hello,

When working with a Stripe Connect application, there are cases where it is necessary (or at least useful) for the application to be able to disconnect accounts that have authorized access to it. A few examples that come to mind are: responsibly sunsetting an application, deactivating a user due to violation of terms and conditions, closing of an account in the third-party application, etc.

However, it seems that currently, the only way to disconnect a Stripe account from a Stripe Connect application is for the owner of the connected account to do this manually from https://dashboard.stripe.com/account/applications.

Can you please offer the equivalent disconnection option to the other party in the Stripe Connect relationship – the application, via an API call? Otherwise, it is impossible to tell Stripe to stop sending webhooks for events that are no longer relevant to the app, and telling users to go to their Stripe dashboard and manually disconnect does not really work.

Thanks,

Vlad

[Michaël Gallego]

Big +1 for this. For now I'm force to send an email with instructions about how to delete the application from their account, by sending some intimidating message like "we are still receiving all your data until you disconnect manually the application", but this is definitely not ideal...

[Brian Krausz]

Sorry for the delay Vlad and Michaël: this has just been released! You can find documentation for this endpoint at https://stripe.com/docs/connect/reference#post-deauthorize.

Thanks for your patience!

--Brian

--
You received this message because you are subscribed to the Google Groups "Stripe API Discussion" group.
To post to this group, send email to api-d...@lists.stripe.com.
Visit this group at http://groups.google.com/a/lists.stripe.com/group/api-discuss/.

To unsubscribe from this group and stop receiving emails from it, send an email to api-discuss...@lists.stripe.com.

[Michaël Gallego]

Thanks !

[Michaël Gallego]

Small question: when we programmatically disconnect an account like this, do we still receive an "application.deauthorized" event ? (I hope not, it would be redundant)

[Brian Krausz]

You do still receive that webhook. I don't find it particularly redundant, as there may be other systems who want to know about a disconnect than the one doing the disconnect itself. This seems analogous to a Connect app creating a charge and still getting a charge.created event. Is there an issue that you foresee that webhook causing?

Thanks,

Brian

On Mon, Nov 10, 2014 at 3:14 PM, Michaël Gallego <mic.g...@gmail.com> wrote:

Small question: when we programmatically disconnect an account like this, do we still receive an "application.deauthorized" event ? (I hope not, it would be redundant)

--

[Michaël Gallego]

Not a big deal, it's just that I suppose typical use case for deauthorizing is when deleting a user. So when you receive again the web hook there is high probability everything is already deleted on my server.

Once again, not a big deal ;)

[Will Ronco]

This is excellent. Thank you very much indeed, Brian!

[Vladimir Andrijevik]

Thanks Brian, this is fantastic!

Cheers,

Vlad

[Vladimir Andrijevik]

Hi Brian,

It seems that the OAuth deauthorize endpoint returns a JSON response (expected), but with a "Content-Type" header of "text/html" (unexpected). I am seeing this even if I set "Accept: application/json" in my requests.

This behavior breaks automatic response parsing (which typically uses the content type to infer a parser), so could you send the correct "application/json" here?

Cheers,

Vlad

[Vladimir Andrijevik]

Sorry for the multiple messages, but just to clarify:

I am seeing "text/html" (with an actual JSON body) on successful responses only. Error responses return "application/json" with a JSON body, so they are not problematic.

Cheers,

Vlad

[Brian Krausz]

Nice catch Vlad, sorry about that!

I've pushed a fix, this should return the correct Content-Type now.

Thanks,

Brian

[Vladimir Andrijevik]

On 21.11.2014, at 12:57, Brian Krausz <bkr...@stripe.com> wrote:

Nice catch Vlad, sorry about that!

I've pushed a fix, this should return the correct Content-Type now.

I just saw that! Thank you very much :)

Cheers,

Vlad