Mail Order Telephone Order (MOTO) payments

[Paul Dailly]

Hi there,

We have a scenario whereby we would like to be able to take a payment from a customer whilst they are on the phone with us. So the flow would be:

1. Customer calls up 

2. Customer calls provides card details to company employee over phone

3. Company employee enters card details into a UI of some sort, and the payment is processed. 

My understanding is the correct way to do this would be to have MOTO payments enabled on our account. Once that is enabled, we could create payment intents where we pass a moto flag (payment_method_options[card][moto]=true) as part of the payment intent creation request.

The downside of this solution is the fact that in order to pass that moto flag when creating a payment intent, we also have to pass the raw card details. In order to pass the raw card details, it means we have to have passed them through our own backend server and then onto Stripe via the API call. Passing those card details through our servers implies taking on a significant level of PCI compliance if I understand correctly.

Is there any other ways to approach MOTO payments that don't involve handling raw card details ourselves?

Thanks,

Paul

[Remi J.]

Hey Paul,

You don't have to send raw card details via the API server-side today. You can use Elements to collect card details client-side that an employee would enter while on the phone and create a PaymentMethod [1]. Then you send the pm_12345 to your server where you can confirm the PaymentIntent with `payment_method: 'pm_123'` and `payment_method_options[card][moto]: true` at the same time.

Hope this solves your issue!

Best,

Remi

[1] https://stripe.com/docs/js/payment_methods/create_payment_method

--
To unsubscribe from this group and stop receiving emails from it, send an email to api-discuss...@lists.stripe.com.

[Paul Dailly]

Hi Remi,

Thanks very much for coming back to me on this one. If the employee were to enter the card details via the Elements widget, is there not a strong chance we could encounter a 3D Secure challenge, as at the point of card entry on client side we haven't declared this payment intent to be a moto payment (and thus exempt from 3DS)? 

I see however you linked to https://stripe.com/docs/js/payment_methods/create_payment_method which seems to be different than the JS SDK method for dealing with setup intents. Is the method you linked to still valid in the context of dealing with 3DS challenges, or should we be dealing with the setup intents API for creating payment methods instead?

Thanks,

Paul

[Remi J.]

3D Secure would happen when you attempt to confirm the PaymentIntent and we contact the bank. This step would be done server-side where you explicitly pass `payment_method_options[card][moto]: true` which indicates the customer is not on session at this point and you're taking their order over the phone.

The key difference here is that you are not confirming the PaymentIntent client-side via Elements like you would for a normal on-session payment. You collect card details that are entered client-side in Elements and create a PaymentMethod instead. This saves the card details in Stripe and give you an id pm_123 that you can then use server-side for the next step where the real payment confirmation happens and the MOTO flag is sent alongside the other information to warn the bank this is a MOTO payment.

Hope this helps!

Remi

[Paul Dailly]

Hi Remi,

Thanks very much for your help. Having tested it, this does indeed appear to solve my problem!

One further question if you don't mind? If I were to attach that payment method to a customer when creating the moto payment intent, and pass setup_future_usage as 'off_session', would that payment method indeed be exempt from future 3D secure challenges if used in an off session manner e.g for a recurring payment or similar?

Thanks,

Paul

[Remi J.]

It will depend on the bank and their own risk decision for future payments so it's not a guarantee, but it's the same as if you had done 3D Secure already. Overall, you can charge it off session, and we will ask the bank and indicate the new payment is off session and they will decide whether to let it through, decline it, or decline it while requiring 3D Secure!

[Paul Dailly]

OK that makes sense - thanks for clarifying.

Thanks again for all your help with this one - much appreciated!