#Nanda-Kumar-MOTO

1 messages · Page 1 of 1 (latest)

inner bough
#

Hi there! Can you provide me a request ID where you are hitting this error?

slim merlin
#

payment intentid?

inner bough
#

A PaymentIntent ID works too if you already have that handy

#

I can get the request iD from there

slim merlin
#

sure will provide

inner bough
#

Thanks!

slim merlin
#

req_MW4N7ahNTAbrY9

#

basically I am using stripe in test mode

inner bough
#

Looking!

#

Looks like your account wasn't correctly configured for MOTO with Direct Charges. I've updated it. Will you test again?

slim merlin
#

sure

#

give me few minne

inner bough
#

no rush

slim merlin
#

The parameter payment_method_options[card][moto] cannot be used when specifying off_session.

#

getting this issue now

inner bough
#

Yep, you can't specify off_session with MOTO. It is implied when you use MOTO that the cardholder is not able to complete authentication but they aren't technically off_session.

#

(missed that you were passing that in your initial request, sorry)

slim merlin
#

the card holder is not in the payment flow coming to our scenario.

#

then in that case we have to set off_session to true right?

inner bough
#

No, off_session is for when you as the merchant initiate the transaction on a recurring basis. This is still the card holder contacting you to initiate the transaction.

#

By passing MOTO, we ask the card networks for an exemption from 3DS, just like we would with off_session. But you don't combine the params as they indicate slightly different things.

#

You should use the proper one for what is happening. If the cardholder contacted you to initiate a transaction, then you should use MOTO.

slim merlin
#

In our case, always merchant initiates the payment transaction instead of the card holder.

inner bough
#

Okay, so why are you using MOTO here?

slim merlin
#

If card holder given the card to merchant, and that is 3D enabled card, then we want to bypass the 3D security

#

and the card will be used in recurring transactions

inner bough
#

Got it and how are you collecting the card details initially?

#

Like are these card details being provided over the phone/mail?

slim merlin
#

through Phone and another way is card older enter through a payment form

inner bough
#

Got it, thanks for clarifying!

#

So, when you initially collect card details over the phone you will use MOTO.

#

Then, for any future payments that use that paymentmethod, whether collected via phone or online payment form, you will not use MOTO but you will pass off_session: true

slim merlin
#

If the card is 3D security enabled, then without MOTO, I will get authetication_required error right?

#

in future payment section

inner bough
slim merlin
#

yes

inner bough
#

MOTO cards will get a request to be exempted from SCA. So most often 3DS will not be required.

#

However it is up to the issuer whether they want to enforce 3DS any way.

#

So you will want to be able to bring your customer back on-session or collect new card details if needed.

#

But this will be rare overall

#

And yes, in that case you will hit authentication_required error.

slim merlin
#

Just I used test 3D card

#

4000000000003220

#

by using Moto flag true

#

and setup_for_future_use = true

inner bough
#

Can you provide the request ID?

slim merlin
#

but the status for the ppayment_intent is "requires_action"

#

req_tNjk2S6MhoEcrK

inner bough
#

Taking a look

slim merlin
#

any findings?

inner bough
#

So it looks like you are attempting to set up future usage on a previously saved card.

#

Here you need to setup future usage on the initial PaymentIntent when you are collecting card details, or use a SetupIntent to collect the card details for future usage.

slim merlin
#

In my product, creating payment method from JS code, then trying to charge the payment method using payment_intent API

inner bough
#

I think you can still use a PaymentMethod with that SetupIntent. Give me one sec to test on my end.

inner bough
#

Still doing some testing, but will circle back. Getting clarity on exactly what you should be doing here.

#

Okay this threw me off for a while!

#

You are actually using the wrong test card here :). That test card will always require Authentication.

#

Instead, test with 4000002500003155

#

That one will require Auth unless it is set up correctly.

#

Yep okay works as expected with that test card.
1/ you create the PaymentMethod
2/ You use payment_method_options: { card: { moto: "True" } }, setup_future_usage: "off_session"
on the first PaymentIntent
3/ You charge that same customer/paymentmethod using off_session: true and removing the above params on future PaymentIntents.

slim merlin
#

Can I perform this flow?

#
  1. create a payment method using JS code
#
  1. Set the payment method while creating setupintent from API by setting moto flag true.
#
  1. Then try to charge the card by creating paymentIntent using API without MOTO flag
#

is it work?

tranquil moat
#

Apologies I missed this thread for a bit. It sounds like the steps you listed are in line with the ones that bismark laid out.

#

Wait, how are you currently creating the payment method without the setup intent?

slim merlin
#

using stripe.js

#

createpaymentmethod

#

function