#lozz_api
1 messages ยท Page 1 of 1 (latest)
๐ Welcome to your new thread!
โฒ๏ธ We'll be here soon! Typically we respond in a few minutes, but sometimes we might take a bit longer if the server is busy or if you have a particularly tricky question.
โฑ๏ธ We close idle threads, which makes them read-only. Once a thread is closed it won't be reopened, but you can always start a new thread if you have another question.
๐ This thread will always be available, even after it's closed. You can find it again using Discord's search, or you can save this link: https://discord.com/channels/841573134531821608/1306178225357197408
๐ Have more to share? Add more details, code, screenshots, videos, etc. below.
The payment method ID and Setup intent ID can both be used as a card token
I don't think this is true. Maybe the wording was different? But Payment Method Id should has pm_xxx format, and Setup Intent Id should has seti_xxx, where token should be tok_xxx
My question is, the payment method ID that gets returned in the response. Could that be used as a card token?
Not really. Payment Method Id is Payment Method Id, can be used in API which requires apayment_methodparameter
Perhaps the API may have changed. We were informed that the "pm_xxx" and "seti_xxx" can be used as a token.
I guess another question would be whether it is possible to return a token after a payment?
As previously mentioned, during our payment request we send the following: amount, currency, payment_method_data[card][number, exp_month, exp_year, CVC], payment_method_options[card][Moto], capture_method and confirm.
Which API are you sending? Is it Create Payment Method API?
Oh you are using MOTO
qq: is your business PCI compliant?
Create PaymentIntent API
We support both Moto and Ecom
Yes
Great. Thanks. I suppose after you call Create Payment Intent, you have a response with a PaymentIntent object, and it should have a payment_method property with a payment method id pm_xxx
Complete reference documentation for the Stripe API. Includes code snippets and examples for our Python, Java, PHP, Node.js, Go, Ruby, and .NET libraries.
Correct, an example response would be:
And the request we would send is:
amount=12300
currency=gbp
payment_method_data[type]=card
payment_method_data[card][number]=*****
payment_method_data[card][exp_month]=02
payment_method_data[card][exp_year]=2023
payment_method_data[card][cvc]=*****
payment_method_options[card][moto]=true
capture_method=manual
confirm=true
Yes and if you create a Customer and pass the customer id in here, the generated Payment Method Id will be attached to the Customer, and you can reuse it in the future
So the Payment Method Id returned in the response can be used as a token for payments if we pass in the customerId?
To be correct, "can be used as a payment method for future payments". You only need payment method, you don't need token
Okay, the payment method Id can be used for future payments. Will this still work if customerId was not passed? I see that customerId is optional.
customer is optional for Create a PaymentIntent API method in general, but for cases where you reuse a saved Payment Method it is required.
Got you, along with the customerId, I'd have to send 'setup_future_usage'?
No, that's when you want to collect a new Payment Method, not reuse an existing one.
At this moment of time, we want to collect a new payment method once a customer has completed their purchase using their card.
We will not be supporting reusing an existing payment method.
Okay then you can use the setup_future_usage property. More details here: https://docs.stripe.com/payments/save-during-payment?platform=web&ui=embedded-form
Just to clarify, in order to save a payment method for future use after a one off payment using a card. I would need to send customerId and setup_future_usage?
Honestly I don't remember if the customer is required at that stage. But I would advise to provide it anyway, so you don't need to attach the Payment Method manually.
Got it, does this principle apply to both moto and ecom?
What do you mean by "ecom" exactly?
Yes, this should be supported.