#wesley_api

1 messages ¡ Page 1 of 1 (latest)

hybrid daggerBOT
#

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

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

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.

lone spire
#

hi! yeah confirmation_method is deprecated.
it depends what flow you want but not setting the return_url really limits you. I assume you have some sort of backend-heavy integration that only processes card payments or something.
If omitting the parameters seems to work in test mode then it seems good! everything you're saying seems sensible enough

lament flare
#

Okay I also had another thread closed now about return_url. Can you confirm that return_url is only used for the result of 3ds?

#

And if it can be any URI or has to be a http(s) uri

lone spire
#

no, it's used for the return from any payment method that involves a redirect to another page (like iDEAL and other payment methods that involve redirecting the customer to their bank)

#

it should always be https

lament flare
#

It sounds like we may need to set that value. Currently we only process creditcard and digital wallet (applepay/googlepay). The operations we do are payments, refunds, (maybe payout) void. for payments we either perform Authorization only and do a manual capture later or Auth+Capture

lone spire
#

what is your plan for handling 3D Secure if required on card payments?

lament flare
#

I would assume (sorry I started in the middle of this project) that we want to treat it as we do on the 2022-11-15 api via SDK. I haven't manually tested the flow in a non frictionless payment, but I know we are already dealing with 3ds.

#

My work is basically stop using (java) SDK and upgrade the API version.

lone spire
#

ok well the first thing I do is test in test mode and see what your current integration does when you use a 3D Secure-required test card.
Ultimately you can avoid setting a return_url; if 3DS is required then you can ignore it, or you can do something like confirm the PaymentIntent again on the frontend, it really depends and there's lots of ways to build this and I don't know what you do currently.

lament flare
#

Thats what I think we were doing sending payment_intent/confirm after 3ds.

#

I've another question if you don't mind directing me.

In our current applepay/googlepay flows we are sending data using extraParams on the sdk. Basically we are sending the fields:

paymentIntent.payment_method_data.card.exp_month
paymentIntent.payment_method_data.card.exp_year
paymentIntent.payment_method_data.card.last4
paymentIntent.payment_method_data.card.network_token.number
paymentIntent.payment_method_data.card.network_token.exp_month
paymentIntent.payment_method_data.card.network_token.exp_year
paymentIntent.payment_method_data.card.network_token.tokenization_method```

I can't find any of these params in your api documentation. Which leads me to wonder if we are sending the correct parameters. Do you have documentation regarding how to integrate assuming we have a decrypted applepay/googlepay card.
#

Sorry the original developer has left, and I can't find the paper trail for why those parameters were chosen/set.

lone spire
#

those parameters are not public, they're for if you're integrating with raw tokens yes, which would be a feature we enabled on your account.
The docs are at https://docs.stripe.com/apple-pay/decrypted-tokens but you need to be logged into an account that has access to the feature to be able to see them

lament flare
#

I may be invited to the wrong account in the company. Thanks this is hugely helpful though.

#

Thats exactly the type of info I needed. I can view that page. Perfect thank you so much.

lone spire
#

awesome

lament flare
#

Which didn't seem to include that info just for your record.

lone spire
#

that's probably a separate thing where we intentionally don't document the payment_method_data.card field because we don't want most merchants to use it(as it's how you pass raw PANs which is something 90% of merchants wouldnt do), alas

lament flare
#

One last thing. Are you okay with me copying the transcript of this conversation into our ticketing system for internal use only? I think its useful for the next person who ends up doing maintainance.

lone spire
#

sure!