#denjaland_api

1 messages · Page 1 of 1 (latest)

wary tokenBOT
#

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

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

novel bisonBOT
#

Below are links to other discussions we've had with you in the past week in case you want to review that information. If your question is related to one of these previous discussions, please provide a comprehensive summary of the current state and what you need help with now. We help many users simultaneously, so a summary allows us to resolve your issue as soon as possible.

novel wolf
#

Does the element not support this?

novel bisonBOT
steel crown
#

No it doesn't support that. Stripe Element on the web doesn't display previously used PaymentMethods

#

You can use/offer Link instead.

novel wolf
#

yes, but link implies the user having setup link to use that

#

so if I want to display their payment methods, I need to manually implement it, right?

#

so GET payment methods for the customer -> display them myself or allow them to select "new card", and move on from there, right?

#

(I understand you want to push link, but there is a reason we moved away from paypal 😉 )

steel crown
steel crown
novel wolf
#

I'm a bit let down about that to be honest. You have great ideas for implementing stuff, but for some reason you always miss the last bits to make them extraordinary - you have all data on file, so when we create a paymentintent on the server for a customer, why would you just not include these saved methods in the elements widget and make the process seamless :-). I remember having discussed this with some of your team years ago, and they were all agreeing, yet so many years later it's still not happening. 😦

#

maybe another small question.
When retrieving an account - how can I easily determine it's the platform account or a connect account? I see the requirements option seems to be missing, but is that how I should check?

steel crown
#

you have all data on file, so when we create a paymentintent on the server for a customer, why would you just not include these saved methods in the elements widget and make the process seamless :-). I remember having discussed this with some of your team years ago, and they were all agreeing, yet so many years later it's still not happening. 😦
Yes I agree with you on that part too. But the idea behind this mainly is to have customizable user flow when using Stripe Element, and let users design their own UI/UX (display Payment Methods)

#

When retrieving an account - how can I easily determine it's the platform account or a connect account? I see the requirements option seems to be missing, but is that how I should check?
As a platform Account you can retrieve only your Connected Accounts, you cna't retrieve other platform Account

novel wolf
#

no, but i'm retrieving my own platform account as well

steel crown
#

Unless I'm missunderstanding you, can you share a concrete example/flow ?

novel wolf
#

well basically the website is setup for multitenancy

#

but we ourselves obviously are also a "tenant"

steel crown
novel wolf
#

no - what we do is $stripeAccount = $stripe->accounts->retrieve($accountId);
so it probably corresponds to GET /accounts/{account}

#

that works for both our account as well as a connected account

#

we have some pages where we display information

#

that page is a shared implementation for our own account as well as our tenant's accounts

#

I prefer to have one implementation there

#

concretely, I'm fetching the account here to display the "activated payment methods"

#

but we also map this: 'is_disabled' => (bool) $this->resource->requirements->disabled_reason,this is now failing for the platform account because the requirements is missing for platform accounts. So I could basicallydo something like 'if platform account then is_disabled = false, else get it from the account' but I'm not sure what the best way is to determine whether it's platform account or not once fetched from your endpoint

steel crown
#

Ok I see, there is no direct way to make the difference. The platform Account is one single AccountId, you can consider it as a constant in your integration (like an env var same as your API key/publishable key)

#

And you simply make the check on that env var to see if it's the platform account or another Connect Account

novel wolf
#

yeah - that's what I was afraid of - it introduces different implementation paths of course

#

but it seems to be the only way indeed 😦

#

fyi - this is the page we're building - we'll have to have separate path for the platform or connected acounts for this :-). If anything stripe could do, is abstract away that distinction - we want to give our business users as well as our tenant admins the same options to managing the "accepted payment methods" 🙂

image.png
wary tokenBOT
steel crown
#

I'm not sure what you mean here exactly ?

f anything stripe could do, is abstract away that distinction
You need to make a check condition if an Account is the Platform or one of the connect Account, I don't think introducing an env var to make that condition check will be different from having a var on the API response to determine if the account is Platform or one of the Connected Accounts.

#

But yes you know your integration better than me at then end 🙂