#akdj16-payment-sheet-setup

1 messages · Page 1 of 1 (latest)

thorny ingot
glad onyx
#

😦 is it planned to add other types in the future?

thorny ingot
#

I'm not certain off-hand, but would encourage you to keep an eye out for updates if it's something that you're interested in. I'm wrapping up another thread but will then double check for any payment method support that was added but hasn't made it into our documentation yet.

thorny ingot
#

I'm really sorry about the delay (the server has been busy today), I'm double checking this with a teammate now.

glad onyx
#

Thank you! I have another question. As the Stripe Element only works with card type setupIntent. I reworked the entire workflow

thorny ingot
#

Everything I'm seeing so far is supporting that currently card is the only type of PMs supported with Setup Intents in that flow. My teammate is testing to confirm, and I'll let you know if that testing shows something different.

Happy to talk through your other question though.

glad onyx
#

previously in others threads, we discussed a lot about how to have multiple discounts on invoice and the first month subscription's payment on Stripe Element and after I presented to my team about what we discussed, my team made a decision to not do the payment with Stripe Element but do an SetupIntent to only attach the payment method, and that is the workflow:

step 1 - User select an subscription offer and confirm the selection
step 2 - After confirm the subscription offer selection, the frontend will send a request to the backend to create a setupIntentSecret and ephemeralKey
step 3 - Frontend will init the Stripe Element sheet with the data from the previous call and displays the Stripe Element
step 4 - User will fill the payment method data and confirm
step 5 - After the attachment is done, the frontend will send a request to the backend to set the payment method as customer's default one
step 6 - Frontend will send a request to the backend to create the subscription.
step 7 - on the backend side, we have a webhook handler for customer.subscription.created and we use this to give to User access to our product/service. We didn't choice to use the paiement.succeeded /invoice.payment.succeeded events because we don't want that user with sepa as default payment method to wait the paiement delay for giving him the product/service access.

so as the Stripe Element with setupIntent cannot handle other than card as paymentMethod.
my team decided to use the paymentIntent, but the above workflow changed and we want to know if the below workflow is or not a good one (we need your expertise and view 🥹 )

#

Sorry about the huge text... 🙏

thorny ingot
#

Alright, I'll keep an eye out for the other workflow that you referenced.

glad onyx
#

step 1 - User will still need to select an subscription offer and confirm the selection
step 2 - After confirm the subscription offer selection, the frontend will send a request to the backend to create a paymentIntent with the amount of the subscription + all discounts to apply (it will not create a subscription, it will only use the price amount)
step 3 - Frontend will init the Stripe Element sheet with the data from the previous call and displays the Stripe Element
step 4 - User will fill the payment method (card, sepa, bancontact, apple pay, google pay) and confirm the payment
step 5 - After the payment is done, normally, the payment method should be also bind on the customer on Stripe platform (we hope), we still don't know how to set this payment method as the customer default one.. as we don't have the setuptintent, payementmethodId, etc
step 6 - Frontend will send a request to the backend to create the subscription
step 7 - The backend will create a subscription with the first month as trial period (for set it to 0€), also it will delete all discounts related to the customer. As we keep the webhook handler for customer.subscription.created and we use this to give to User access to our product/service.

#

here is it 🙂

#

we have four questions about this workflow:

  • is this flow is a good one ?
  • do we will face to 3ds process on subscription with trial ?
  • how can we set the payment method as default one?
  • are there other risks?
thorny ingot
#

That sounds like a good flow.

When creating the Payment Intent in Step 2, if you set the setup_future_usage parameter to off_session then we do everything we can to optimize the Payment Method that is created for future off-session usage. That process also attaches the created Payment Method to the Customer that the Payment Intent is created for.
https://stripe.com/docs/api/payment_intents/create#create_payment_intent-setup_future_usage
If a Customer isn't provided to the Payment Intent, then you will need to explicitly attach that Payment Method to a Customer.

That doesn't set the Payment Method as the default Payment Method for the Customer though, to do that you'll need to update the Customer's invoice_settings.default_payment_method value with the ID of the Payment Method that was created:
https://stripe.com/docs/api/customers/object#customer_object-invoice_settings-default_payment_method
You can find the ID of the Payment Method associated with a Payment Intent on the Payment Intent object:
https://stripe.com/docs/api/payment_intents/object#payment_intent_object-payment_method

#

There isn't a risk of 3DS being needed when a Subscription with a trial is created, because the Subscription's first Invoice will be a zero-dollar invoice so it won't process a payment.

There is a possibility that future renewal attempts may require 3DS though, so you'll need a flow to handle that scenario in case it arises.

glad onyx
#

Ok! Thank you, I will forward these replies to the team 😃 i will keep you updated

thorny ingot
#

Sounds good!