#johan
1 messages · Page 1 of 1 (latest)
Hello! We'll be with you shortly. 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.
- johan, 4 days ago, 19 messages
hello! can you share your code snippet?
sure!
following this exact same tutorial: https://stripe.com/docs/payments/payment-intents/moto#future-payments
gimme a while to get back to you
np at all take your time!
i'm not super familiar with TypeScript, but if i refer to the code, it exists : https://github.com/stripe/stripe-node/blob/master/types/SetupIntentsResource.d.ts#L76
yeah no worries, card seems to be missing in the PaymentMethodData in the interface
I still haven't made any requests so I assume it'll work?
is this parameter new?
yep, it'll definitely work. It's not new but we don't encourage usage of raw PAN. You should only be using it if you're PCI compliant. You'll probably need to ignore the warnings
okay so my idea is to collect the card data with the CardElement in the client and send this data to that endpoint and create the setupIntent. I assume this is the right way since I want to collect my customers payment method via MOTO transaction so I want to avoid SCA and speed up the onboarding flow
can you please confirm this
onesec, so you're using the CardElement internally?
as in, letting your Customer Support Staff key in those card details?
yeah we want to create a flow where customers call us and they provide the card details via MOTO (mail order, telephone order) so we collect those details, store the payment method in their account and assign them a subscription.
I assume this is what this tutorial is for https://stripe.com/docs/payments/payment-intents/moto#future-payments
but we obviously need to insert the card data dynamically to that endpoint instead of the '42424' etc
hrm, wouldn't it be easier for your team to email the customer a hosted invoice page or payment link which they can key in their own details?