#gleb-test-card
1 messages · Page 1 of 1 (latest)
@quiet rivet the flow you have is really not optimized and something we discourage.
Instead you should do
- BE creates a subscription with
payment_behavior: 'default_incomplete' - FE confirms the underlying PaymentIntent client-side as it collects payment method details
But when you do step #3 in your flow, we try to validate the card with the bank which rejects it and fails the request. That's what happens with that test card
does that make sense?
@harsh rapids Thank you. So it should be:
- BE creates a subscription with payment_behavior: 'default_incomplete';
- FE confirms the underlying PaymentIntent client-side as it collects payment method details;
- ??? FE/BE attaches the payment method to the customer;
- ??? FE/BE updates a default payment method for the customer in their invoice settings;
As for the payment confirmation, in case when FE confirms the payment, BE cannot accept it as a source of truth. Because the client could intercept the request and send a confirmation to the BE without paying their bill.
I guess the only way here is to use webhooks on BE side to confirm the payment.
There's no #3 and #4, it is done automatically for you
Try it in Test mode, should take a few minutes at best
@harsh rapids I tested all the described flow. It's just Stripe examples here: https://github.com/stripe-samples/subscription-use-cases/blob/master/usage-based-subscriptions/server/dotnet/Controllers/BillingController.cs do exactly what I described. See CreateSubscription method.
yeah not all samples have been updated
@harsh rapids the documentation you sent says that there should be #4:
Server
You now have an active subscription belonging to a customer with a payment method, but this payment method won’t automatically be used for future payments. To automatically bill this payment method in the future, use a webhook consumer to listen to the invoice.payment_succeeded event for new subscriptions and set the default payment method.```