#maaaaah_cvc-recollection-paymentmethods
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/1221861301379272784
๐ Have more to share? Add more details, code, screenshots, videos, etc. below.
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.
- maaaaaaaaaaah_api, 5 days ago, 50 messages
additional questions:
- The Sources API has been deprecated, does it only affect sources or does it also affect other routes/resources such as Cards?
- Is the StripeJS #createToken method something that is also deprecated or not recommended for setting up new cards for future usage? (I was generating tokens from cards prior from the upgrade but I recently moved to setupIntent + confirmCardSetup)
- Does the PaymentIntent accepts cvc_token for both PaymentMethods and Cards? (when I say card I mean informing the card as a payment method)
Complete reference documentation for the Stripe API. Includes code snippets and examples for our Python, Java, PHP, Node.js, Go, Ruby, and .NET libraries.
Complete reference documentation for the Stripe API. Includes code snippets and examples for our Python, Java, PHP, Node.js, Go, Ruby, and .NET libraries.
HI ๐
We recommend avoiding both Sources and Cards and relying on Payment Methods instead. What are you trying to do?
We recommend avoiding both Sources and Cards and relying on Payment Methods instead
Does it also includes using a 'card token' (card_iY1827189...) on Payment Methods?
What are you trying to do?
My goal is to re-collect the customer CVC and have it be sent to stripe via PaymentMethod as a cvc_token (through the payment_method_options.card object ) and have it validate/invalidate the PaymentIntent
The paymentIntent is created on the server (backend) with the confirm_method set to manual and confirm to true (I would like to obtain the error right away if there are any, which should result in the record not being commited)
So you keep re-collecting the CVC for stored cards? So the customer is on-session when you charge them?
So you keep re-collecting the CVC for stored cards?
That is something I would like to do but only for checkouts (we are doing a custom checkout), the goal is to send the cvc_token along with charge data to the PaymentIntent and have it be validated from there. We don't have CVC recollection now but is something we would like to add as a way of increasing security while allowing card re-usage.
So the customer is on-session when you charge them?
The customer is on-session when the record is validated but off session when the charge is confirmed/captured
Wait but that doesn't make sense
The cvc_token is only good for 10 minutes.
So the customer should still be on-session if you are passing that along with the payment intent
The cvc_token is only good for 10 minutes.
That is the scope of it, the Payment will happen almost inline
When you say 'on-session', do you mean an authenticated user or something else?
I mean the user is interacting with your application
I see, in this case, yep, they are.
I am afraid I confused you with the terminology and for that I am sorry. The PaymentMethod creation happens 'on-session'
With that, can both Cards and PaymentMethods be used as payment_method for PaymentMethods?
If so, do they both would accept the cvc_token or only the PaymentIntent with a PaymentMethod of type PaymentMethod?
Sorry for the delay
So with the Customer on-session, what is it you are hoping to prevent with the CVC collection?
I feel like we're close to having a recommended approach ๐
Card reusage, for example, many commerces store your card and allow customers to re-use it during checkout
What I'd like to do is to recollect the CVC and have a way of preventing people that have access to your account from generating charges with your card
Okay...
That said, would PaymentIntents accept the cvc_token for both PaymentMethods(pm_12345) and Cards(card_12345)?
So you can use the Card CVC Element in Stripe.js with a Payment Method to re-collect CVC
So you don't even do the tokenizing yourself.
We show this approach here https://docs.stripe.com/payments/save-card-without-authentication?platform=web#web-recollect-cvc
Where the CVC is recollected when confirming the payment intent
In case the PaymentIntent is only created on the server and at the very end.
Could the same behavior be achieved through the create CVC token https://docs.stripe.com/api/tokens/create_cvc_update endpoint
Via PaymentIntent?
In that case you would be collecting the CVC yourself to get it server-side, which I do not think we recommend
That puts you into PCI compliance terriroty if I'm not mistaken
I see
Instead of doing the PaymentIntent via stripe.js, could I then use stripe.createToken('cvc_update') and proceed from there then?
The paymentIntent through stripe.js would not work for our case I'm afraid =/
In that case it sounds like creating the token client side: https://docs.stripe.com/js/tokens/create_token?type=cvc_update, then passing it back to the server and using it when creating/confirming the Payment Intent https://docs.stripe.com/api/payment_intents/create#create_payment_intent-payment_method_options-card-cvc_token is the most clear path forward for you.
Thank you, I'll proceed with the above change
About the other question, would both Cards and Payment Methods be accepted and validated through the approach above?
or would only PaymentMethods be valid a payment_method value?
I think so but I would want to test that out thoroughly first.
No, we don't know whether or not a CVC is valid unless we ask the issuing bank
And, you should be aware, issuing banks will sometimes allow charges even if the CVC check fails. You can prevent this with Radar rules though
I see
but in case a wrong cvc_token is informed, the paymentIntent ought to fail when I try to confirm it, right?
Here are the docs for thishttps://docs.stripe.com/disputes/prevention/verification
I mean, for the cases where it's supposed to be 'validated'
but in case a wrong cvc_token is informed
I'm not sure what you mean here. A bank may return acvc_check: "failed"but still allow the charge when you confirm it
I understand
That answers all of my questions
Thank you so much for your time @sand river and sorry for bothering you
I hope you have a great day!
Great ๐ I'm happy we were able to get this squared away ๐
It's not a bother, it's why we're here.