#jaybabu_best-practices
gaunt vineBOT
đ 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/1478439535145648131
đ Have more to share? Add more details, code, screenshots, videos, etc. below.
rapid spire
Based on my experience so far, I would say that it depends on the complexity of your use case. v2 recipient accounts will bring a lot more features, but are also more complicated to work with and reason about.
If you are building a relatively simple payments integration you might be better served with v1 Customers
harsh rapids
we currently have 0 stripe customers with this new way so want to go down the latest recommended practice
can you share more on what you mean more complicated to reason about?
rapid spire
sorry I said "recipient account" but I meant Customer accounts
Well, the v2 account is a larger object with more parameters and things like requirements . I think the standard use case for v2 accounts with a customer configuration is connect platforms that want to both facilitate collection of payments on their connected accounts but also charge them for services. In the past there were some options for debiting connected accounts, but mostly people created a v1 Customer and then collected a payment method and charged them like any other customer, but they had to maintain the state of the connected account and its relationship with the Customer on their end and the objects had no relationship in Stripe. Now you can combine them.
I would recommend reading this doc to give you an idea of what is intended:
I am not yet aware of a compelling reason to use v2 accounts over v1 Customers for a standard payments integration
harsh rapids
it is likely we will be doing both debiting and paying these customers
subscriptions, one off invoices, future invoices, credits are part of scope
rapid spire
If you need to pay them, then v2 accounts might be something you want to explore
harsh rapids
our legacy set up for connected accounts for liquor stores involved creating both the account v1 and a customer v1 to pay and invoice them. that we migrated to v2 and has been great
okay, i will give it a shot it seems like. thank you!
most customers we will mostly be charging them and not paying, but seems like it would be best to not keep a fork in the logic
rapid spire
Yeah I have only done a little testing on Customer-only v2 accounts, but I think there are some advanced billing features they're meant to be useful for
harsh rapids
we will definitely be doing invoicing like 30 day terms but i think that can be done in either setup
rapid spire
Yep
harsh rapids
is there any doc that shows what you gain if you use accounts v2 for customers that you couldn't do in customer v1 (and what you lose or becomes harder)
rapid spire
Not yet. Though we do have this doc that is specifically about representing Customers as accounts on the v2 Accounts API:
So you would likely want to read that as well
harsh rapids
yeah, i think that is what i sent
thank you!
sorry, there was one more thing
it is separate from this
https://docs.stripe.com/payments/save-and-reuse
we wanted to do this but when they use the card for the first time, we want the user to verify their CVV/CVC and zip code. how can we do that?
they would verify when actually trying to use their card
rapid spire
Is the first card use a one-off payment (PaymentIntents api) or a Subscription/Invoice?
harsh rapids
one off
like when collected the info?
we would collect the information using the stripe terminal, sorry this article https://docs.stripe.com/terminal/features/saving-payment-details/save-after-payment
rapid spire
Gotcha, and then you're charging the generated card later?
harsh rapids
yes correct
during that time for the first use, we want to verify the cvv and zip code
to minimize fraud. without that, the cashier could just attach their own profile, get the customer to use the credit card and now the cashier can use the credit card in a fraudlent manner
rapid spire
I think you're looking for this parameter: https://docs.stripe.com/api/payment_intents/create?lang=node&api-version=2025-12-15.clover#create_payment_intent-payment_method_options-card-require_cvc_recollection
harsh rapids
perfect! thank you. only cvc is possible?
rapid spire
Yeah I'm not certain that we don't recollect postal code as well though in the Payment Element
I would test it
harsh rapids
do you know where it is normally passed?
rapid spire
What's that?
harsh rapids
like where zip code & address is normally passed in
rapid spire
Sorry I may have made an assumption.
From your question, I assume that at some time after the original payment, you want to charge the generated card from your original card present payment on some sort of web dashboard or other context where the customer is online and present in the checkout. I also assumed you would be using the Stripe Payment Element for this. Is any of that incorrect?
harsh rapids
we would simply charge the card on file. do we need to use the checkout session or payment element? the intent is to set "off_session" https://docs.stripe.com/terminal/features/saving-payment-details/save-after-payment?terminal-sdk-platform=server-driven#create-paymentintent
rapid spire
But cvv/cvc isn't stored - recollecting cvc is for on-session payments
harsh rapids
okay, i see. so if you want cvc recollection, you have to use payment element? we can't use our component to take in CVC. guessing that is for compliance reasons
rapid spire
Right, storing CVC isn't allowed. If you want to recollect cvc on each payment, you would have to bring the Customer on-session each time, and since they need to have something to enter the cvc into, you'd most likely use the Payment Element
gaunt vineBOT
harsh rapids
okay, is there a way to know if the CVC has ever been verified for the payment method? would the payment include that information?
rapid spire
Yeah, there is a checks property on the Payment Method https://docs.stripe.com/api/payment_methods/object?lang=node&api-version=2025-12-15.clover
rapid spire
You're welcome!
harsh rapids
i just tried it out. seems like it would be best to use accounts v2 for creating future customers. no real difference
other than preview limitations
glad rampart
Hi there,
took over for my colleague who had to step away. Yes, generally speaking v2 accounts should work just as expected. We also (somewhat) recommend using v2 accounts since they are the future, but v1 will still stick around for a bit
harsh rapids
makes sense, thanks
glad rampart
No problem. Always happy to help