#gbyesiltas_api

1 messages · Page 1 of 1 (latest)

tight muralBOT
#

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

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

lament tendonBOT
tiny swift
#

Hi there 👋 I'm taking a look, but we don't recommend this client-only checkout flow anymore so I'm a bit rusty on it and will need a bit to dig in further.

bright escarp
#

Hey! Thanks for the quick reply 🙂 I see, I wanted to use the client-only checkout for the low-effort first implementation but I should be able to implement the one with the server-side flow if that turns out to be what I need to get iDeal to show-up 🙂 Just curious, why are you guys not recommending the client-only flow anymore?

tiny swift
#

I do think I'd suggest the server-side approach here. Client-side integrations are more susceptible to javascript tampering and things of that nature. For instance a not-so-trustworthy customer could sniff your code, find your success_url, and try to just hit it directly.

Server-side integrations keep the settings controlled from a more secure environment.

#

I'm not quickly spotting a way to specify specific payment method types when creating the session client-side, and the resulting checkout session doesn't seem to be pulling in values from your billing settings.

#

I do think server-side is going to be required, but I'd recommend trying a quick test and make sure the options appear as you're expecting before putting too much effort into it. To make sure I'm not missing something else.

bright escarp
#

Hmm, even with the server-side, from my understanding (mostly here), if I don't specify the payment methods the checkout page is supposed to get the relevant payment methods for the customer automatically and I can then manage the payment methods I want to support from the dashboard. That does sound pretty good so if possible I would prefer to avoid specifying the payment methods while creating the checkout session in the code even if I have to switch to server-side.

you mentioned

the resulting checkout session doesn't seem to be pulling in values from your billing settings.

Do you think it could be the reason why iDeal isn't showing up?

#

I do think I'd suggest the server-side approach here. Client-side integrations are more susceptible to javascript tampering and things of that nature. For instance a not-so-trustworthy customer could sniff your code, find your success_url, and try to just hit it directly.
About this, I do handle the payment success stuff with webhooks, I don't really do anything on the success url except to show a success message so I should be fine for now 😄 Though I understand how this could be an issue in general

#

In any case, in the meantime I'm looking into switching to server-side 🙂

tiny swift
#

Yes, when I look at the Checkout Session that is created by the client-side integration, the only value I'm seeing in payment_method_types is 'card', which I believe explains why you aren't seeing the iDEAL.

#

iDEAL is a little tricky here since you're creating a subscription Checkout Session, as those use iDEAL to create SEPA payment methods.

bright escarp
#

the only value I'm seeing in payment_method_types is 'card', which I believe explains why you aren't seeing the iDEAL
Ah interesting, payment_method_types isn't even a paramter in the client-side method so I guess it just falls back to this at some point.

iDEAL is a little tricky here since you're creating a subscription Checkout Session, as those use iDEAL to create SEPA payment methods.
Yeah may be. Though it is still quite popular to see iDeal for subscription payments (for any sort of online payment really) in the Netherlands

tiny swift
bright escarp
#

Oh hey, the server-side flow did work!

#

I didn't have to specify the payment methods explicitely

tiny swift
#

Yess!

bright escarp
#

Cool, I guess this was the good-practice anyways 😄

#

But it may be nice for you guys to document this somewhere if this is expected behaviour cause I didn't really see anything related to having less options on the client side checkout

tiny swift
#

Agreed, that's what I was hunting for as well