wulff-13-3ds-android

[pine mason]

@crisp vortex hi! It depends a lot on how exactly you use the SDK. Which components are you using exactly to accept the customer's card and process the payment?

[crisp vortex]

I only use the CardInputWidget

[pine mason]

ok! So that gives you a PaymentMethod or Token I believe. What do you do with that once you have it?

[crisp vortex]

I send it to our backend and it will respond with a success or a requires SCA authentication, and from there I dont know what to do

[pine mason]

you should be following this guide anyway : https://stripe.com/docs/payments/accept-a-payment?platform=android&ui=custom

yeah sending it your backend is not correct and is a legacy way to do things.

you should create a PaymentIntent on the backend, return it to the frontend, and call paymentLauncher.confirm which will process the payment and present a 3D Secure interface if needed.

note the docs are written for the latest version of the SDK which was released a couple of weeks ago(https://github.com/stripe/stripe-android/blob/master/CHANGELOG.md#1720---2021-09-10) so make sure you're using the latest, then follow that guide.

[crisp vortex]

I do get a payment intent back, created on the server. We create a payment method on the client first though. This works fine for iOS and web. Do I not need to pass the payment intent to the paymentLauncher.confirm?

[pine mason]

you do need to pass it to paymentLauncher.confirm yes!

since you're doing it slightly backwards you'll have to adapt the code a little

for example you probably want to pass the PaymentIntent back, then use https://stripe.dev/stripe-android/stripe/com.stripe.android.model/-confirm-payment-intent-params/-companion/create-with-payment-method-id.html instead of ConfirmPaymentIntentParams.createWithPaymentMethodCreateParams and then pass those params to the launcher

[crisp vortex]

So the guide I linked is not the right one?

[pine mason]

the guide is https://stripe.com/docs/payments/accept-a-payment?platform=android&ui=custom since you're trying to accept a payment using the CardInputWidget and that's the documented approach

[crisp vortex]

Okay, I'll try that

[pine mason]

you split the flow differently than our default approaches though so you'll have to understand and adapt that code

[crisp vortex]

Yeah all I have is a payment intent

[pine mason]

by default it's create PI on backend -> send to frontend -> complete payment entirely on frontend

[crisp vortex]

Yes, that

's what I do

[pine mason]

you're doing create PaymentMethod -> send to backend -> create PI -> return to frontend

[crisp vortex]

Yes, but only if using a non-saved card

I mean the last part should be identical, no?

You end up with a PI in both cases

[pine mason]

well sort of yes in that you're confirming the PaymentIntent locally

but for example this :

you won't be doing that ConfirmPaymentIntentParams.createWithPaymentMethodCreateParams since you already created the PaymentMethod previously

[crisp vortex]

Yes I thnk that's where it's going south for me

[pine mason]

but ultimately you want to construct a ConfirmPaymentIntentParams with the PaymentIntent/Method details and call the confirm method yes

[crisp vortex]

Okay, thanks

[crisp vortex]

So what I needed to do was create a ConfirmPaymentIntentParams without the params from the payment method, using this constructor instead:

        /**
         * Create a [ConfirmPaymentIntentParams] without a payment method.
         */
        @JvmOverloads
        @JvmStatic
        fun create(
            clientSecret: String,
            shipping: Shipping? = null,
            setupFutureUsage: SetupFutureUsage? = null
        ): ConfirmPaymentIntentParams {
            return ConfirmPaymentIntentParams(
                clientSecret = clientSecret,
                setupFutureUsage = setupFutureUsage,
                shipping = shipping
            )
        }

[pine mason]

yep, makes sense!