#fkaib

1 messages · Page 1 of 1 (latest)

rapid hollowBOT
#

Hello! We'll be with you shortly. Below are links to other discussions we've had with you in the past week in case you want to review that information. If your question is related to one of these previous discussions, please provide a comprehensive summary of the current state and what you need help with now. We help many users simultaneously, so a summary allows us to resolve your issue as soon as possible.

main ether
#

Hello

#

How are you canceling the Subscription?

warped pewter
# 
    try:
        subscription = stripe.Subscription.delete(subscription_id)
        db.collection(ACCOUNTS).document(user.user_id).set({"plan_type": "free"}, merge=True)
        return subscription
    except Exception as e:
        raise HTTPException(
            status_code=400,
            detail="Unable to delete subscription"
        )```
#

I just delete it. Is it better to cancle it as shown in the link you sent?

main ether
#

Nah you are just using an older version of the SDK which works fine

#

If you want to charge the customer though you should pass invoice_now: true

rapid hollowBOT
warped pewter
#

I have another question.

The reason why I need to delete the payment methods is because of the way I implemented the subscription and payment. When the user clicks on a button "Subscribe", I create a subscription withpayment_behavior='default_incomplete', payment_settings={'save_default_payment_method': 'on_subscription'},. Once the subscription was successfully made, I display the <PaymentElement /> using the pending_setup_intent where users enter their payment method.

When the user cancles a subscriptpion and clicks on the "Subscribe" button again, this time it will create a subscription with the previous payment method before providing their payment method in the <PaymentElement />. Is the only way to prevent this to delete all the payment methods from the customer when they cancle the subscription?

dusky bobcat
#

Stepping in as bismark needs to delurk. Let me catch up here!

warped pewter
#

HI!

dusky bobcat
#

Hi, if you do not intend to use the old PaymentMethod, you can detach it from the customer, https://stripe.com/docs/api/payment_methods/detach. This, payment_settings={'save_default_payment_method': 'on_subscription'}, should save the payment method on the suscriptions. Can you share the object id with me so I can further look?

warped pewter
#

I just don't want to detach the payment method before the payment is complete. If I detach all the payment methods from a customer when the subscription is cancled with invoice_now set to true, will the payment be made? Or is there lag in completing the payment?

by object id, do you mean the subscription object? Here is the subscription id sub_1OcDfpEvUNDxHSmfAZ2u3bAj

dusky bobcat
#

I see. In this case you'd need to detach the payment method as it's set as the default payment method on the customer object. You can cancel the subscription with invoice:now, and then create the new subscirption.

warped pewter
#

I see. Also when managing the subscription in my database, I am using the stripe webhook. Currently i am using the "setup_intent.succeeded" to detemine whether the has subscribed or not. However I am not sure if this is the best event to use. Also what will be a good even to update the database when the subscription ends?

dusky bobcat
warped pewter
#

but can't the subscription.created trigger before the payment method has been established?

#

I only want to update the subscription status once the payment is attached to the subscription.

dusky bobcat
#

Ah, you're collecting the payment method first, then creating the Sub. In that case, you're right, you can listen to setup_intent.succeeded and then listen to customer.subscription.created event to determine that they've subscribed.

#

Just listening to setup_intent.succeeded does not mean that the Sub. was created.

warped pewter
#

Interesting. How do you keep track of two consecutive events like that?

dusky bobcat