#hooky_api

1 messages · Page 1 of 1 (latest)

tough forgeBOT
#

👋 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/1235215593825632268

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

lapis pelican
#

I wonder if the reason this fails is because the reactivated subscription I created I created it using Stripe Connect and not the custom API Key the customer gave me. Maybe that's it? But if so... is there a way to fix the existing subscriptions? e.g. can I change which account owns a subscription? No, right?

#

Here's one example:

#

(Note the new sub is missing the Transfer Destination, because we didn't realize we needed to copy that field too. But now... is there a way to fix these subscriptions?)

#

I apologize if my messages are confusing. I am trying to wrap my mind around this whole thing myself. 😄 😄 😄

wraith heath
#

Yeah I have a feeling this is related to connect stuff. The subscription you're trying to updated was created on the account by the platform (as a direct charge) which you're trying to update using the account's API key.

While the object does belong to the account (acct_1M7K5aBgsjiCxQa9) since this is a direct charge, I don't think you can create transfer to its connected account

#

In this scenario

Platform == the account that created the subscription on acct_1M7K5aBgsjiCxQa9
Connected account == acct_1M7K5aBgsjiCxQa9
(Grandchild) connected account == acct_1OL8B5JxXVrZDx6z (the account you're trying to set under transfer_data.destination

lapis pelican
wraith heath
#

Its for the request ID you shared initially... which is trying to update sub_1P9SvYBgsjiCxQa9P5SYyuIB

lapis pelican
#

Ah, cool cool.

wraith heath
#

The error makes sense here

The error: "You cannot make a destination charge on a connected account. You must either make the request on your own account (by using your platform's API key, and not using the Stripe-Account parameter), or remove the destination parameter."

The platform this account acct_1M7K5aBgsjiCxQa9 is connected to created the subscription using Stripe-Account header. So it is considered a direct charge.

You can't update Direct charge to contain transfer_data since that's for destination charges

lapis pelican
#

Ahhh I see

#

so we as a platform made a big mistake here, affecting around 300 subscriptions.

#

can you think of any suggestion to remediate this? or there's nothing?

wraith heath
#

I don't think you can update these existing subscriptions. Your only option might be to create a new subscription using connected accounts API key and cancel the old ones.

lapis pelican
#

Something that confuses me a bit:

#

Usually we perform operations using our own platform Stripe Key + we pass the stripeAccount to the Stripe API.

#

But for cases like this, where the customer gave us a custom API Key, we use their key instead. However, we still pass the stripeAccount (which should be unnecessary if we're using their key, and is a mistake on our end, I believe) - could that still be causing this? (I'd think maybe Stripe would ignore the stripeAccount argument in these scenarios?)

#

In other words: Moving forward, for future subscriptions, if we keep using that correct API Key but stop sending the stripeAccount should that allow us to set the transfer_data field?

wraith heath
#

But for cases like this, where the customer gave us a custom API Key, we use their key instead. However, we still pass the stripeAccount (which should be unnecessary if we're using their key, and is a mistake on our end, I believe) - could that still be causing this? (I'd think maybe Stripe would ignore the stripeAccount argument in these scenarios?)
If you're using the connected account's keys then what value are you setting to stripeAccount header?

lapis pelican
#

For example this specific organization, our customer, Mr Wash, has connected to us using Connect and we stored their stripeAccount ID: acct_1M7K5aBgsjiCxQa9

#

So we can do certain things like list their subscriptions and whatnot, using our own key + that stripe account ID.

#

But for certain operations we need to use the API Key they gave us. Presumably, for creating subscriptions with destination charges.
But we were (and now I think this was a mistake on our end) running those calls while also including Stripe Account ID = acct_1M7K5aBgsjiCxQa9

wraith heath
#

The subscription sub_1P6wtuBgsjiCxQa9q1ld6ga1 was created using Platform (Churnkey) API key + Stripe-Account header set to acct_1M7K5aBgsjiCxQa9

lapis pelican
#

Aaaaahhhhhh

#

Good point

#

And if I had used the right API Key (Mr Wash's) while passing a Stripe-Account, Stripe would probably throw an error, no?

wraith heath
#

If you were to create the subscription with acct_1M7K5aBgsjiCxQa9's API key with acct_1M7K5aBgsjiCxQa9 set as Stripe-Account header then it would likely just ignore the account in the header

#

OR return an error 🤔 I haven't tried it myself

lapis pelican
#

Ahhhh, I see. Perfect, makes sense.

#

It's fine, either way, we should be using their API Key. Which in fact I thought we were. We must have a bug there.

#

Okay.

#

This makes sense, thank you! I may need a bit more help about this later. Should I post again in here? Or open a new ticket?

wraith heath
#

The thread might be closed but you can always open a new one for any follow ups 🙂

lapis pelican
#

Allright, thanks a ton! Things are much more clear now. 😄 Thank you for your patience! ❤️

wraith heath
#

NP! 🙂 happy to help

fwiw

If you were to create the subscription with acct_1M7K5aBgsjiCxQa9's API key with acct_1M7K5aBgsjiCxQa9 set as Stripe-Account header then it would likely just ignore the account in the header
The API just ignores the header if the API key belongs to that account.
Just tested this by creating an example PaymentIntent

lapis pelican
#

Ahhh, you reminded me of something

#

Another question;

#

For our "reactivation" process where we'll start a new sub for a customer who had churned...

#

We have a page with Stripe Elements, use a SetupIntent, etc...

#

I probably need to set the data_transfer there, too, right? Not only when creating the subscription.

#

(and/or on_behalf_of)

#

(Ahhh, connected to that last question... I see I was failing to use the customer's custom Stripe API Key when creating the SetupIntent. I was using our platforms's key + stripeAccount. I wonder if that is part of the issue.)

wraith heath
#

Not sure. Like SetupIntents don't support transfer_data parameter.
https://docs.stripe.com/api/setup_intents/object

You'd use SetupIntent to store a PaymentMethod on the child platform (the account connected to your platform). If you're only going to charge it with a specific merchant then you can use on_behalf_of parameter to specify the connected account (the connected account that's connected to the child platform) as merchant of record

lapis pelican
#

Ahhh then there's probably no need to do that.

#

All I need, really, is to mimick the exact transfer_data and on_behalf_of from the old subscription, and have the same values in the new subscription when I "recreate it". (Again, this is for a churned end-customer who is coming back)

#

For that, it seems it's enough to...

  1. Use the customer's API key when creating the setupintent and payment method; but no need to use on_behalf_of
  2. When creating the actual subscription, also use the customer's API key, and set the transfer_data and on_behalf_of values that the old subscription had.
#

As I re-read this and your last message, I don't know... perhaps it is a good idea to specify on_behalf_of during the setupintent process, too.

#

But for the goal I described, is that mandatory? that would be helpful to know.

wraith heath
#

I think the decision to use on_behalf_of depends on if you need the platform to be the Merchant of Record or the connected account.

Like, it is possible that the card holder may see $0/$1 temp auth charge on their statements. Which merchant info should be shown there? If platform, then you don't need to use on_behalf_of but if you want connected account information to be shown then you'd use on_behalf_of

lapis pelican
#

That's helpful. Thanks!

#

Allright, that's all for now. Thank you!!! 🙂

wraith heath
#

NP! 🙂 Happy to help