#peter-subscriptions
vale acorn
there's a few ways to do this, but https://stripe.com/docs/payments/checkout/subscriptions/update-payment-details is one of the easier/better ones.
dense pond
Great
This uses Stripe Checkout
We currently handle that within our app without redirecting
Presuamby if we were to create a new paymentMethod, attach this to the customer and then update the subscription it would work?
vale acorn
you can do that too, but that's what the CheckoutSession is doing already
you also often want to 3D Secure authenticate the card when its being saved, which Checkout will do here
dense pond
Ok, the main issue we have with Checkout is the branding and the fact it runs on a stripe domain
vale acorn
ok
dense pond
We want to keep people on our domain
vale acorn
then https://stripe.com/docs/payments/save-and-reuse is the guide you want
you use a SetupIntent and our UI components to accept and save the payment method
dense pond
I understand Checkout is the bees knees
If we can host that under our own domain then we would likely use it
vale acorn
as far as I know that is something we're working on and might have a beta for, but it will be an extra cost.
dense pond
We also have some "edge case" flows.. such as completing transactions for 2 seperate stripe accounts in one go
We operate stripe connect
And use direct charges
vale acorn
fair enough! Anyway, you don't have to use Checkout, you can use a SetupIntent directly on your own pages(similar to how you use a PaymentIntent from the Subscription Invoice to start the subscription I assume) without a redirect
dense pond
We are old skool. We create the customer, then a payment method on the front end and create the subscription this way
vale acorn
it's fine to be "old skool" but do you handle 3D Secure authentication when it's required? That's the only point I want to make. It's really important to authenticate the first payment of a subscription so you qualify for SCA exemptions on the recurring payments, and also to authenticate card when saving them without payment(like updating billing details for a subscription) you get exemptions for credential-on-file. That's why Payment/Setup Intents exist and you can't use legacy Tokens/Charges APIs in 2022's payment industry.
you 110% do not have to use Checkout, you can build all this natively into your page and not redirect.
dense pond
Yes, we do if its required
vale acorn
great! so, any other questions or something I can clarify? If you want the "update your subscription payment method" flow, then https://stripe.com/docs/payments/save-and-reuse?platform=web is the way to go
dense pond
When we setup the subscription, we send the payment intent secret to the front end
Will this always ask them to verify things?
vale acorn
it depends, but if 3D Secure is required or recommended then a SetupIntent using our stripe.js libraries will prompt for it yep!
dense pond
I think we want to rework our flows
and start create the paymentIntents and subscriptions on the backedn and then pass these to stripe.js
confirmCardPayment
Does this encapsulate the confirm for payemnt intent and setup intent?
vale acorn
confirmCardPayment confirms a PaymentIntent, that's it.
you need two different flows here, one for starting a subscription (involving confirmCardPayment-ing the PaymentIntent you get from subscription.latest_invoice to complete the payment and authenticate it), and one for updating a payment method (involving confirmCardSetup-ing a SetupIntent you create for the purpose, to authenticate and save a payment method to the Customer object)