#luanvdw-Subscription

1 messages ยท Page 1 of 1 (latest)

grand sequoia
#

Hi there, I don't quite understand your question. Can you explain your business logic?

hybrid bramble
#

Hi Jack, sure thing!

Currently we are creating subscriptions in the following manner

  1. ensure that a user has a default payment method (we save a card with a setup intent in another flow)

  2. create a subscription for the user with charge_automatically

  3. Stripe then uses the default payment method for the first charge on the subscription (this is automated by Stripe)

  4. if the first payment fails then the subscription goes into incomplete and we enter the realm of payment recovery

What would be the best way to capture payment upfront upon which if successful, we will only then process to subscribe a user. If not then we are dealing with card errors such as a declined card.

grand sequoia
#

So basically you want to charge your customer upfront to reduce the number of card declines?

hybrid bramble
#

10000%

#

Yes ๐Ÿ˜„

grand sequoia
#

There's a possibility that the card will get declined even though the first paymentIntent was succeeded. So my opinion is that your current flow is good enough and you shouldn't complicate the logic by introducing another upfront payment.

hybrid bramble
#

our current flow however does not cater well for 3DS so I am looking to make modifications to it in any case, so I would appreciate your advice on how to best deal with that

so in a completely separate flow we are capturing card details (with no payments) this is just a "Add card" modal that I then store as the user's default payment with setupIntents and Stripe Elements

Now we have a default payment Method

The act of creating a subscription allows Stripe to do its charge_automatically bit on the back. My question however now becomes with this charge_automatic bit how would I best cater if a customer has some 3DS requirement at this stage.

If it comes up during the flow of simply adding a card, then Stripe Elements will cater for it... great!

But with the second flow... how would this be handled?

Or how would I need to rework the flows to better cater for this?

grand sequoia
#

If you are using SetupIntent and PaymentElements, the customer will experience the 3DS flow during the payment_method collection flow and may not be asked for 3DS authorization in the future recurring payments. However, we can't 100% guarantee that the customer will not encounter 3DS again as the issuing bank may request 3DS if it believes the transaction is risky.

#

So your application shall always be prepared to handle the 3DS flow (i.e., when the PI status is requires_action)

hybrid bramble
#

Ok thank you for this, so just to confirm

currently we are only using setupIntent in flow A and then creating a subscription in flow B (without the use of paymentIntents, we just have charge_automatically on the subscription create)

So in order to rely on the status of a payment intent, we would need to update flow B to create subscriptions with the use of paymentIntent(s)

grand sequoia
hybrid bramble
#

Ah I see, oki thanks!

Final question just to ensure I understand the various paths to implementation correctly.

If I take a payment X for $20 and it succeeds (through a paymentIntent + confirmPaymentIntent)
Is it possible to link this payment to a subscription on subscrption create

For example,

  1. Capture payment
  2. Link captured payment on subscription create, for example something like stripe.subscription.create({ paymentIntent: })

// I know the above example does not exist, but is there a way to link an already captured payment to a subscription at this point?

grand sequoia
#

I think what you want is to save the payment_method that you collected in the 1st payment, and reuse it in the subscription, is my understanding correct?

hybrid bramble
#

That already works, when setting it to defaultPayment method that is what Stripe will use.

I am more thinking of if our subscription prices are fixed... and I create a paymentIntent for $20 and capture it

With a random payment having been captured (that is not linked to anything) is it then possible to link it to a subscription when creating said subscription

grand sequoia
#

I won't recommend this approach, a few reasons

  1. Not scalable, what if you decide to change the subscription price later? how do you handle trials
  2. Not a great user experience, your customer get charged twice (1st is the paymentIntent, 2nd is the first invoice of the subscription)
  3. Hard to handle proration, there's no proration logic for ad-hoc paymentIntent