jaybabu_best-practices | Stripe Developers | Page 1

gaunt vineBOT Mar 3, 2026, 5:10 PM

#

👋 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 Mar 3, 2026, 5:12 PM

#

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 Mar 3, 2026, 5:12 PM

#

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 Mar 3, 2026, 5:13 PM

#

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:

https://docs.stripe.com/connect/accounts-v2

#

I am not yet aware of a compelling reason to use v2 accounts over v1 Customers for a standard payments integration

harsh rapids Mar 3, 2026, 5:18 PM

#

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 Mar 3, 2026, 5:19 PM

#

If you need to pay them, then v2 accounts might be something you want to explore

harsh rapids Mar 3, 2026, 5:20 PM

#

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 Mar 3, 2026, 5:23 PM

#

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 Mar 3, 2026, 5:24 PM

#

we will definitely be doing invoicing like 30 day terms but i think that can be done in either setup

rapid spire Mar 3, 2026, 5:24 PM

#

Yep

harsh rapids Mar 3, 2026, 5:25 PM

#

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 Mar 3, 2026, 5:27 PM

#

Not yet. Though we do have this doc that is specifically about representing Customers as accounts on the v2 Accounts API:

https://docs.stripe.com/connect/use-accounts-as-customers

#

So you would likely want to read that as well

harsh rapids Mar 3, 2026, 5:27 PM

#

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?

Save a customer's payment method without making a payment

If you want to onboard customers now, set them up for payments, and charge them using the Payment Intents API in the future, and use the Setup Intents API to save a customer's payment method without making a payment.

#

they would verify when actually trying to use their card

rapid spire Mar 3, 2026, 5:41 PM

#

Is the first card use a one-off payment (PaymentIntents api) or a Subscription/Invoice?

harsh rapids Mar 3, 2026, 5:42 PM

#

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

Save payment details after payment

Accept an in-person payment and save payment details to use later, when the customer is not present.

rapid spire Mar 3, 2026, 5:43 PM

#

Gotcha, and then you're charging the generated card later?

harsh rapids Mar 3, 2026, 5:43 PM

#

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 Mar 3, 2026, 5:45 PM

#

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 Mar 3, 2026, 5:45 PM

#

perfect! thank you. only cvc is possible?

rapid spire Mar 3, 2026, 5:46 PM

#

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 Mar 3, 2026, 5:47 PM

#

do you know where it is normally passed?

rapid spire Mar 3, 2026, 5:48 PM

#

What's that?

harsh rapids Mar 3, 2026, 5:48 PM

#

like where zip code & address is normally passed in

rapid spire Mar 3, 2026, 5:51 PM

#

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 Mar 3, 2026, 6:03 PM

#

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

Save payment details after payment

Accept an in-person payment and save payment details to use later, when the customer is not present.

rapid spire Mar 3, 2026, 6:06 PM

#

But cvv/cvc isn't stored - recollecting cvc is for on-session payments

harsh rapids Mar 3, 2026, 6:07 PM

#

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 Mar 3, 2026, 6:11 PM

#

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 Mar 3, 2026, 6:18 PM

#

harsh rapids Mar 3, 2026, 6:22 PM

#

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 Mar 3, 2026, 6:23 PM

#

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

harsh rapids Mar 3, 2026, 6:25 PM

#

perfect! thanks so much

#

i have everything i believe

rapid spire Mar 3, 2026, 6:27 PM

#

You're welcome!

harsh rapids Mar 3, 2026, 7:02 PM

#

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

#

https://docs.stripe.com/connect/accounts-v2/saas-platform-payments-billing#preview-considerations

Compare SaaS platform configurations for Accounts v1 and Accounts v2

Learn how a SaaS platform charges its connected accounts with Stripe Billing using Accounts v2.

glad rampart Mar 3, 2026, 7:05 PM

#

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 Mar 3, 2026, 7:06 PM

#

makes sense, thanks

glad rampart Mar 3, 2026, 7:07 PM

#

No problem. Always happy to help

#jaybabu_best-practices