#luceos_customer-defaultpm

1 messages · Page 1 of 1 (latest)

uncut wigeonBOT
#

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

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

vestal hazel
#

luceos_customer-defaultpm

#

👋 It depends a bit on your overall integration and how you set the default payment method in the first place.
But at a high level I recommend using the CustomerPortal https://docs.stripe.com/customer-management to collect new payment method details and control this

flat ingot
#

so i tried doing this and supplied the on_behalf_of key to the portal session create with the connect account id, it still says "no such customer"

#

or do i need to leave that out?

vestal hazel
#

How are you integrating in the first place here? Like what type of connected accounts and what flow of funds have you picked?

flat ingot
#

they're standard accounts, they use the oauth flow to connect them from inside my app

#

i use one-off payments and subscription based, both with platform fees

#

but the payment information needs to become updateable only for the subscription based ones, obviously

#

brb, kids need to be put in bed 😊

vestal hazel
flat ingot
vestal hazel
#

not sure I follow what readme you are talking about but if you have a question I'm happy to help

flat ingot
#

i meant putting some documentation in place what kind of stripe integration i use 😄

#

as a todo for myself

vestal hazel
#

ah gotcha!

#

Can you give me an example Subscription id? I can figure it out quickly on my end from that

flat ingot
#

sure one sec

#

sub_1P1t4ELqbNjl2ZDkMCJUP1Ju

vestal hazel
#

Okay so you seem to be a Connect platform using Standard accounts and using the Direct Charges flow where you create all the objects directly on each individual connected account.
Does that resonate/make sense?

flat ingot
#

it does and that makes my question hard to answer, isn't it?

#

😊

vestal hazel
#

No, just making sure that's correct

#

So when you use Direct Charges, the flow is basically that your code makes all API requests directly on that connected account. And that applies for everything in the future. So taht also would apply for the CustomerPortal calls.

Earlier you said you tried with on_behalf_of and that's the part that didn't make sense. You were making the call on your Stripe account instead of on that connected account

flat ingot
#

i assumed on_behalf_of implies the connect account

#

but i must have misunderstood the docs in that particular area

#

hm, i think i understand

#

so i need to use the token from the connect team/user to create the customer portal session

#

this is part of my question though, the other part is about updating ALL payment methods of ALL connect accounts for that particular user, is that possible in some way?

#

I can imagine that if the user uses the customer portal to update their payment information I can allow my app to cascade that update to any other connect account that this user/customer is making use of?

vestal hazel
#

so i need to use the token from the connect team/user to create the customer portal session
what do you call "the token"

flat ingot
#

the oauth token that the developer stores while connecting their stripe account as a connect account

vestal hazel
#

In theory what you call the "oauth token" has been deprecated back in early 2015 and highly discouraged from being used except in really rare cases 😅

#

Are you hosting the code of your whole platform? Or is this a "self hosted plugin" where people install your code on their own server?

flat ingot
flat ingot
#

these users sign up on the website, ask to be allowed to publish "premium" extensions (plugins) and then need to connect to a stripe account and github to publish their extensions from github with plans from stripe

#

i guess i need to invest some time in a refactor

vestal hazel
#

conceptually it works the same, but instead of having 2000 API keys for 1000 connected accounts, you have 2 (your own keys) and that's it :p

#

Does that make sense? You don't have to change anything yet, but that helps align on the vocabulary

flat ingot
#

i remember in one version of the api that on_behalf_of acted as similarly to this header

#

or is that just my imagination speaking

#

i'm using the php library, so I'll have to check how that translates into that code

vestal hazel
#

yeah that's a misunderstanding on you end, it never was that

flat ingot
#

gotcha

vestal hazel
#

on_behalf_of does exist and it's when you make all payments/calls on your own account but say which connected accounts gets a portion of the funds

flat ingot
#

hm i'm looking at the code and notice i'm not actually using the stripe oauth token at all anymore 🙈

vestal hazel
#

lol

flat ingot
# 
        return Session::create($payload, [
            'stripe_account' => $plan->stripeToken->stripe_user_id
        ]);
#

it does use the token, but only to get the stripe user id, which is the acct_ thing

vestal hazel
#

okay good

flat ingot
#

i guess that's what i need to use for the portal as well, isntead of on_behalf_of, the stripe_account

vestal hazel
#

So now, you said "across all connected accounts" which confused me.

Are you saying that you store some of the customer information at your platform level? For example if I pay for product X on account acct_1234 and later come back and order product X on acct_ABC do you remember who I am, my card details, etc.?

flat ingot
#

a user signs up on the website, they then go through the checkout of a subscription for .. let's say "Extension A" by connect team A, they then want a subscription to "Extension B" by connect team B. The customer fills in their details every time.

My question relates to being able to update their payment details on every connect account at once, for every active subscription

vestal hazel
#

Yeah I was just making sure. Some platforms do store card details at the platform level for example

flat ingot
#

as these details are stored per connect account, there's no one call

#

i don't

vestal hazel
#

So yeah to answer your question: that is impossible.

flat ingot
#

i try to push that security risk to you

#

hm ok

#

what if.. I allow the user to edit their payment information using a customer dashboard/portal for one subscription;
I then listen to the change event
store the payment information temporarily
push that to every other subscription they have on other connect accounts?

#

(probably when they click a checkbox "update this payment information change to all my subscriptions")

vestal hazel
#

yeah that's not really possible. There's no way for you to "propagate" that change to all the other connected accounts

flat ingot
#

the other solution to get this done in the future is to change my implementation so that customers and subscriptions are owned by the platform account and the connect accounts just take a fee, right?

#

i know i've been asking a lot of your patience, thank you for all this help by the way 🙏

#

i feel like i need to dive back into the stripe docs about the connect topic to really understand what would be best moving forward

vestal hazel
#

the other solution to get this done in the future is to change my implementation so that customers and subscriptions are owned by the platform account and the connect accounts just take a fee, right?
kind of, but that comes with a lot of other changes such as you owning liability for negative balances, no Dashboard access for those connected accounts, etc.
It's possible for sure but it's a complete business model shift

flat ingot
#

i am aware

vestal hazel
#

(and really no worries at all, you ask clear questions and they are all totally reasonable for our Discord server, I'm happy to help!)

flat ingot
#

thanks

vestal hazel
#

I'm glad you're aware. 90% of my time here is explaining those gotchas because almost no one gets them (even though they are the fundamental first decision for using Connect 😅 )

flat ingot
#

i can imagine a user having 30 subscriptions at some point and having to go over all of them when having to change their payment information because it cannot be managed centrally

#

well i in fact made a well based decision on how i wanted connect to be implemented, i built the whole website myself and know the ins and outs, but all options within stripe and what does and doesn't work with connect sometimes throws me off 😛

#

and this one question has made me feeling dumb for quite a few days now

vestal hazel
#

I totally get it. This is such a subtle side effect of using Direct Charges. I've worked here a long time so I know this inside out

flat ingot
#

i wish i know what you know 😛

vestal hazel
#

My team just published a video https://www.youtube.com/watch?v=X-VKDdk052Q that explains how you do "Direct Charges with cloning". It technically could work for you, but you lose all the other benefits of the CustomerPortal where they show Subscriptions and Invoices and such.
But conceptually if you wanted that one feature, that's how you'd do it: collect all payment methods on the platform and clomne those to right connected account(s)

flat ingot
#

I'll have to check that out.

#

aside from the country specific additional requirements, the cloning is exactly what i need if a new payment method can be set as default and can/will be used on all existing subscriptions of said customer, or will it be used as a fallback?

uncut wigeonBOT
vestal hazel
#

You can control everything with the API. So you can set the new PaymentMethod as the default on the Customer. But if you already explicitly set a default per Subscription you'll ahve to override that.

My advice though is to never do that yourself. I know it looks useful but it won't work for many cases (cloning is only for a couple payment methods) and it will make it really hard to map that to what happens in the CustomerPortal (where the end customer can change their payment method but you can't apply that to other accounts)
I was sharing this more for "completeness" but platforms like yours using Direct Charges + Standard accounts + Checkout + the CutomerPortal really won't be able to do this flow well

flat ingot
#

i am actually not relying on the customer portal at this point

#

i planned to introduce it so that customers can change payment information, but them having to do so for every connect account is just a hassle

#

maybe not with the 10- connect accounts active now, but I guesstimate it growing fast the coming year or two

#

My advice though is to never do that yourself.

Care to explain to what exactly you refer here? Setting payment methods as default or setting a default per subscription?

vestal hazel
#

Trying to do that platform-wide flow of management when you use Standard accounts that can have their own actions in the Dashboard, especially as you use Checkout (where they will always get a brand new payment method on each new Subscription).
Overall you are just going to spend your time trying to patch things.

#

I have to run but @shy elm is taking over if you have follow up questions

flat ingot
#

thanks for your time @vestal hazel i very much appreciate it

#

i think i'm okay with the answers you gave, and i've become a lot wiser..

#

Feels like I should've asked more questions here in the past years 😊

shy elm
#

lol glad to hear you are making progress