#andrew_rundoo-MOTO

1 messages · Page 1 of 1 (latest)

round snow
#

Elements is not the way to go with MOTO afaik

#

Elements is not the way to go with MOTO

#

one min

#

Have you had a convo with Support and did they enable your account via that?

olive otter
#

Yep!

round snow
#

Did they provide any Doc link for MOTO?

olive otter
#
#

just those two

#

I don't think either of them covers what I'm asking about

round snow
#

Um that't not enough I agree. There is another Doc but can I have your account id (acc_xxx) and the email you used? Will try to find the conversation

olive otter
#

acct_1HQMA1JFfb8SRu7A

round snow
#

Okie can confirm you are in 😄

#

Can you see this?

#

It's pretty much explained there, but generally with MOTO you have the card detail already, so you only needs to call Stripe API from server side and not worry about client SDK such as Elements

olive otter
#

yep I can see that!

#

it seems unfortunate that I would be passing these details in plain text though

round snow
#
  1. can I use Elements just to generate a tokenized version of a card without giving it a payment intent
    You can't, since Elements is a different flow
  2. if I render my own UI (i.e. don't use Elements), how do I tokenize the card details from the client so that I'm not passing the card details in an API call
    The device environment where your operator receiving card information from customer should be secure already. You can build a simple UI for them to input the card detail, and a secure network to a server that take the card detail directly and call the API like the Doc
#

Customer -----(phone)----> Operator ----(some UI takes the card detail)-----> Secure server ------(call Stripe API with card[moto]=true) ------> Stripe

olive otter
#

So I'll still be PCI compliant if I am passing those card details in plain text to my own API that then hits the stripe API? I won't store them in our database.

round snow
#

You would need to be PCI compliant for that connection.