mayhu-subscription-default | Stripe Developers | Page 1

pure sable Jun 15, 2022, 6:29 PM

#

@steady viper yes you can set it globally if you want

#

no need to override on the subscription if the customer already has a default

steady viper Jun 15, 2022, 6:30 PM

#

perfect, thanks!

molten zephyr Jun 15, 2022, 6:31 PM

#

(unless the customer WANTS more than one subscription, AND wants them to be on different cards...)

pure sable Jun 15, 2022, 6:32 PM

#

sure but that is kinda obvious in itself

molten zephyr Jun 15, 2022, 6:32 PM

#

(...and you want to support that. You don't have to)

steady viper Jun 15, 2022, 6:36 PM

#

Are there are any docs on what the flow typically looks like for charging a customer a second time, after they already have a payment method set up?

We currently use the new Stripe payment element to charge users within our platform, and we save their card for future use. If the user wanted to buy a 2nd product on our platform, we ideally don't want to show them a Stripe payment element again, because we already have their card on file. What should we be showing them instead?

pure sable Jun 15, 2022, 6:40 PM

#

@steady viper the default payment method is purely for Invoices and Subscriptions. It doesn't work for normal one-time payment

#

PaymentElement today doesn't have any UI/flow for showing a previously saved card/payment method really so you have to build this yourself

#

It's something we want to fix in the future, but it'll take a while

steady viper Jun 15, 2022, 6:52 PM

#

Got it. Our platform supports a mix of one time payments & subscriptions so this is how I'm thinking about it:

User selects product/price
If they are a first time customer, show them payment element (this is what we curr have implemented)
If they already have a payment method on file, display a custom UI that shows them we're about to charge their existing card on file (with the option to change if needed, which would then direct them to the payment element)
If the repeat customer is buying a one-time purchase, create & immediately confirm the payment intent on our server (https://stripe.com/docs/payments/save-and-reuse?platform=web#charge-saved-payment-method)
If the repeat customer is purchasing a new subscription, create the new subscription (which will immediately charge them the first invoice?)

#

So I guess my question is, what kind of UI should we showing our users if step 4 or 5 results in an error? If we attempt to charge a saved payment method, and it results in an error, do we show them the entire payment element again?

I've noticed on other sites I've used, they sometimes ask for JUST my CVV if they already have my card on file. Is that something we should be doing?

pure sable Jun 15, 2022, 6:53 PM

#

yes I would show the PaymentElement again in that case

#

We have a CVC recollection feature https://stripe.com/docs/payments/save-during-payment-cards-only#web-recollect-cvc but it's not compatible with PaymentElement for now. And I don't recommend building this honestly. If you get a decline, then ask for a new card and delete the old one after the successful payment (assuming they want the new one to be the new default)

steady viper Jun 15, 2022, 6:58 PM

#

I see. So is there a difference between selecting "on_session" vs "off_session" for "setup_future_usage" when creating a payment intent? Which one should we choose? (https://stripe.com/docs/api/payment_intents/create)

#

It seems like with this flow, it doesn't really matter which one we choose. Because we're not "taking advantage" of the fact that the customer is in the middle of our checkout flow when we charge their card a second time

pure sable Jun 15, 2022, 7:00 PM

#

There is a real difference yes on many levels

#

You are not supposed to use off_session: true at your step 4 if the customer is on session since that breaks various rules such as SCA for card payments in Europe

#

so really you have to choose what is relevant to your business model. Will you charge customers off session in the future, where they are not on your website/application and you charge them, like recurring payments for example are off session

steady viper Jun 15, 2022, 7:03 PM

#

Well for us, if the user purchases a subscription, then we need off session to be true (because we need to charge their card every month). But if the user just purchases a one time thing, then we don't need off session to be true. Because we only charge users for one time purchases while they are on session

pure sable Jun 15, 2022, 7:05 PM

#

correct so since both might happen I'd do setup_future_usage: 'off_session'

#

but you can't pass off_session: true on PaymentIntent creation if the customer is on session in your app or on your website attempting to pay

steady viper Jun 15, 2022, 7:07 PM

#

I see, so during our step 4, when we create the payment intent for the repeat customer, we should do confirm=true & off_session=false?

pure sable Jun 15, 2022, 7:08 PM

#

yes, or just don't pass off_session at all, it's the default

steady viper Jun 15, 2022, 7:09 PM

#

So the docs say this: "Set off_session to true to indicate that the customer is not in your checkout flow during this payment attempt—this causes the PaymentIntent to throw an error if authentication is required."

If off_session is set to false, what happens if authenticated is required?

pure sable Jun 15, 2022, 7:18 PM

#

it goes to next_action and you handle client-side

molten zephyr Jun 15, 2022, 7:22 PM

#

(Incidentally, my app does exactly this, and it works fine - the customer is sent an email to return, and the paymentIntent is recreated (re-used, really) with off-session: false to specifically generate the client secret and the needed state for when the customer does get back to the site)

steady viper Jun 15, 2022, 7:31 PM

#

Are there any docs on how to handle next_action? Since the only method we support right now is cards, I imagine the most common next_action type would be "use_stripe_sdk" or "redirect_to_url". If the type for next_action is "use_stripe_sdk", how/where do we pass that to Stripe.js?

pure sable Jun 15, 2022, 7:32 PM

#

You use confirmCardPayment() client-side

#

https://stripe.com/docs/js/payment_intents/confirm_card_payment

steady viper Jun 15, 2022, 7:33 PM

#

Oh so is "next_action.use_stripe_sdk" essentially the same thing as the payment client secret?

pure sable Jun 15, 2022, 7:39 PM

#

maybe? 😅 that sentence as is doesn't really make sense unfortunately

#

but mostly if it says "use_stripe_sdk" then you go client-side and confirm it the same way you would have if you were collecting new card details, just you don't need the card element

steady viper Jun 15, 2022, 7:41 PM

#

oh I see, so the client-side confirmation doesn't require any input from the user?

pure sable Jun 15, 2022, 7:43 PM

#

no input, but it might require an action like entering the 2FA code they got for 3D Secure for example

#

and it can still be declined, in which case you'd show the PaymentElement again

steady viper Jun 15, 2022, 7:45 PM

#

Got it, I think that makes sense. Will test it out and see if it all connects! Thanks so much for all the help, i really appreciate it

pure sable Jun 15, 2022, 7:46 PM

#

Happy to help! Going to add @candid badger to take over as I have to run in case you have follow up questions

#mayhu-subscription-default