#pavlos_91429
prime forum
Yeah authentication is always a possibility
But you wouldn't create a payment intent
You'd create a subscription
weak panther
True, I'd create a subscription. Would this be API-side then? ^
What if the payment method requires authentication? Which payment methods may require authentication? For this use case I'm only interested in cards.
Also, the name default_payment_method confused me a bit. When I create a subscription, isn't there a single payment method? Is there any chance that the default is not used?
vapid canopyBOT
ornate marsh
Hello! I'm taking over and catching up...
Yeah, you would create the Subscription on your server using the Stripe API.
If the payment requires authentication the payment will fail with a decline code of authentication_required and you handle it like any other decline at that point: bring your customer back on-session and have them attempt to pay again, either with the saved card or a new payment method.
Multiple Payment Methods can be attached to a single Customer. The default_payment_method property on a Subscription specifies the specific Payment Method belonging to the associated Customer that you want to use for that Subscription.
weak panther
Thank you. Do we know which payments may require authentication or not?
Also, in the case the payment gets declined and I want to bring them back on session. How would I then attempt to pay again but using an existing payment method?
i.e. without them having to enter card details again
ornate marsh
There's no way to know ahead of time if authentication will be required or not. The card issuer decides if authentication is required at the time of the transaction.
You can attempt payment again with their saved Payment Method, yeah, and do it as an on-session payment using Stripe.js so the Customer can handle authentication if it's required.
weak panther
Aha, that link was quite helpful. So instead of a {PAYMENT_INTENT_CLIENT_SECRET} I assume I would use a new {SUBSCRIPTION_CLIENT_SECRET}
And when I call this function from Stripe.js, I don't need to pass Elements as an argument right?
As I probably wouldn't have an Elements instance at that point (since the payment method is saved from beforehand)
ornate marsh
There is no SUBSCRIPTION_CLIENT_SECRET. Subscriptions generate Invoices, and Invoices create Payment Intents, and you need the client secret from the Payment Intent of the latest Invoice for the Subscription.
Correct, there is no Elements instance in this scenario.
weak panther
Yes, true, sorry for the confusion!
You've been really helpful. One last question before I go home; when I create this subscription as we mentioned (in a user session), what are the best practices for storing this information in my database. As in, I've now called confirmCardPayment, authentication has completed. Would the best way to update my database be webhooks at this point? Or do usually people instantly call their API after confirmation to update the necessary tables/documents?
(I have another question as well, but since it's completely unrelated, I won't post it in this thread)
ornate marsh
It depends on the flow you're trying to build, your business needs, etc.
You can post all your questions in this thread.
weak panther
I'm planning to also include Apple Pay and Google Pay as payment methods available for subscriptions for iOS and Android respectively - our Web client will only have cards.
We already covered saving cards as payment methods above, which is now quite clear.
How would we go creating subscriptions with Apple Pay and Google Pay? I'm looking at this guide: https://stripe.com/docs/apple-pay
Make an endpoint that creates a PaymentIntent with an amount and currency. Always decide how much to charge on the server side, a trusted environment, as opposed to the client side. This prevents malicious customers from choosing their own prices.
I'm assuming that for subscriptions, instead of a payment intent, my endpoint should create a subscription and should return the client secret of the Payment Intent of the latest Invoice for the Subscription? Or would that not work for Apple Pay?
I saw that in these docs: https://stripe.com/docs/api/payment_methods
There is no mention of Apple Pay and Google Pay in payment method type, why is that? Are they not handled as payment methods?
ornate marsh
Apple Pay and Google Pay are subsets of the card type. You create Subscriptions with them basically the same way you would with any other card.
weak panther
Ah, interesting. Thanks!