#gleb-test-card

1 messages · Page 1 of 1 (latest)

harsh rapids
#

@quiet rivet the flow you have is really not optimized and something we discourage.
Instead you should do

  1. BE creates a subscription with payment_behavior: 'default_incomplete'
  2. 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?

quiet rivet
#

@harsh rapids Thank you. So it should be:

  1. BE creates a subscription with payment_behavior: 'default_incomplete';
  2. FE confirms the underlying PaymentIntent client-side as it collects payment method details;
  3. ??? FE/BE attaches the payment method to the customer;
  4. ??? 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.

harsh rapids
#

There's no #3 and #4, it is done automatically for you

#

Try it in Test mode, should take a few minutes at best

quiet rivet
harsh rapids
#

yeah not all samples have been updated

quiet rivet
#

@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.```