#dragon.frost

1 messages · Page 1 of 1 (latest)

sullen charmBOT
real ibex
#

Hi there!

#

Why not first create the Subscription and use the PaymentIntent (or SetupIntent) created by the subscription itself?

zealous lodge
#

The thing is I have a requirement which requires that a user has payment method attached to them before creating a trial subscription. For this, I created a setupintent and then created a subscription with trail enabled which sets the subscription's status as trailing.

So, for cases when there is no trial I was thinking to have it as a similar flow as well rather going back and forth with the payment intent flow

real ibex
#

The thing is I have a requirement which requires that a user has payment method attached to them before creating a trial subscription. For this, I created a setupintent and then created a subscription with trail enabled which sets the subscription's status as trailing.
Yes that works.

#

So, for cases when there is no trial I was thinking to have it as a similar flow as well rather going back and forth with the payment intent flow
For non-trial Subscription this flow would also work, but it's not great. Because customer might run into 2 3DS flow in a row: one for the SetupIntent and one for the first payment of the Subscription.

#

That's why we recommend first creating the Subscription and then using the PaymentIntent of the Subscription itself.

zealous lodge
#

Thanks.

#

Another question I'm very confused about:
What is the difference between invoice.payment_succeed and invoice.paid

real ibex
#

There are very similar, with one difference.

  • invoice.payment_succeeded: Occurs whenever an invoice payment attempt succeeds.
  • invoice.paid: Occurs whenever an invoice payment attempt succeeds or an invoice is marked as paid out-of-band.
zealous lodge
#

Ah! my bad. thats straight forward.

#

is invoice.payment_succeed and/or invoice.paid called when creating a subcription with a trial? Is it called again after trail ends and on each subsequent purchaes on subscription

real ibex
real ibex
#

👋

#

You should be able to post now, sorry about this

zealous lodge
#

regarding this situation you mentioned previously:
#1157232104338374727 message

For non-trial Subscription this flow would also work, but it's not great. Because customer might run into 2 3DS flow in a row: one for the SetupIntent and one for the first payment of the Subscription.
That's why we recommend first creating the Subscription and then using the PaymentIntent of the Subscription itself.

I have a situation that checks if a user is eligible for trial or not, only at the backed before creating a subscription. So assuming a subscription plan has trial included, I will go through the setupIntent flow. But on the backend, I want to check if the user is eligible for trial or not. If not, I would want to go throught the paymentItent flow after that. Regardless, seems like I have to do the setup intent and paymentIntent both with this approach.

So is there a proper way to do this?

real ibex
#

So is there a proper way to do this?
Sorry I'm not sure I follow. Like I said before, the best flow is to first create the Subscriptions and then reuse the PaymentIntent/SetupIntent created by the Subscription, to avoid having two 3DS in a row.

zealous lodge
#

Sounds good.

#

So is there a proper way to check if a card is valid or not before creating a subscription without using setupIntent?

bronze rivet
#

Hi! I'm taking over from my colleague. Please, give me a moment to catch up.

bronze rivet
zealous lodge
#

I want to do this because, I have a use case where I have to ensure that a user has a payment method attached to them before creating a subscription with trial.

bronze rivet
#

Why you don't want to use SetupIntents?

zealous lodge
#

Because I want to avoid this situation if a subscription doesnot have a trial.

#1157232104338374727 message

I have a situation that checks if a user is eligible for trial or not, only at the backed before creating a subscription. So I want to have a simpler flow as much as possible.

bronze rivet
#

You can collect a Payment Method with SetupIntent and then create a Subscription with or without trial. What's the problem with this approach?

zealous lodge
#

Well @real ibex mentioned on the thread I linked above.

If I do setup Intent and then create a subscription without trial, customer might run into 2 3DS flow in a row: one for the SetupIntent and one for the first payment of the Subscription.

#

I think I would want to avoid having 2 3DS flow in a row

bronze rivet
#

I think there's a misunderstanding. You don't need any actions from the customer if you use a saved Payment Method, you just create the Subscription and it charges the saved PM immediately. If it's correctly set up there shouldn't be any problems. In rare cases, if the bank requires 3DS again, you will need to ask the customer to provide another card, but this is not a normal situation.

zealous lodge
#

Oh cool, thank you. So are you saying @real ibex might be mistaken on what they said?

#

For reference, I'm calling setup intent and create subscription endpoints in a single user action.

bronze rivet
#

No, maybe your requirements were not 100% clear to us at first. It's a lot about aligning on terms and concepts at first. Sorry for confusion.

bronze rivet
zealous lodge
#

No, when a user clicks on the action button to purchase subscription, my flow is:

  1. Create setup intent
  2. Attach the card to customer and create a subscription
  3. Confirm the subscription payment on frontend with confirmCardPayment if the subscription does not include a trial.
bronze rivet
#

I don't understand how "Create setup intent" and "Attach the card to customer" can be in 1 action. When does the customer type in the card details?

zealous lodge
#

By one action, I mean after the customer types in card details and clicks the Submit button. "Create setup intent" and "Attach the card to customer" both actions happen on the submit button click.

bronze rivet
#

I think there's still a bit of confusion here.

zealous lodge
#

Oh yes thats right.

#

I got confused it seems

bronze rivet
#

You can actually do this without creating an extra SetupIntent. The standard approach is, when you create a Subscription without a payment_method, you will either get latest_invoice.payment_intent.client_secret or pending_setup_intent.client_secret, depending on if there's a trial or not, that you can use to collect a payment method on the frontent. It will be attached to the Subscription and move it to "active" state. Why you don't want to use this approach?

zealous lodge
#

If there is a trial, when creating a subscription, I want to make sure that the user has payment method attached to them.

Because lets say I created a subscription with trial, it will immediately mark that subscription as trailing. But later, if the card declines when collecting the payment method at the frontend then the user already has a subscription assigned to them but not any payment method on them.

#

I want to avoid this

bronze rivet
#

I see, you want it to be incomplete until the customer adds the card? Then the previous approach is better.

zealous lodge
#

yes. Thanks

zealous lodge
bronze rivet
#

Yes.

#

Sorry, it seems like Discord has some connectivity issues.