#Eranga

1 messages ยท Page 1 of 1 (latest)

valid grove
#

Hello @echo rune! let me test something and get back to you

#

@echo rune yep it's possible. You would need to get the underlying PaymentIntent for that particular invoice of the subscription

echo rune
#

Could you guide me through the workflow you did?

valid grove
echo rune
#

Wow... I am not using Stripe Elements for now

valid grove
#

how were you planning to charge the user when they added a new card?

echo rune
#

I didn't explore Stripe elements. I am going to create a customer, and a subscription using API. Then I am going to show the user the customer portal to add a credit card. Then I wanted to charge the customer as soon as they entered the card details

#

And that is where I don't know how to trigger a payment for the customer

valid grove
#

@echo rune the use case you just mentioned seems a bit different from the original use case - Originally, it was about when a recurring payment fails. This recent scenario is about charging a customer when they first sign up for a subscription

echo rune
#

Yes, sorry about the confusion. So let's say I have created a customer and the subscription in Stripe using the API. Assume the customer have a credit card setup as payment source as well.

One day the payment fails. I want to know how can I ask the customer to add a payment source and charge immediately when the user added it ๐Ÿ™‚

valid grove
#

I feel there are a couple of options :

you can leave it to Stripe to send a reminder. Stripe will send an email reminder to the customer to update their billing info if a recurring payment fails. I'm not 100% certain if the new card will be charged immediately once it's been provided - you'd have to test this out. In any case though, if you've configured the subscriptions to retry if payments fail, it'll automatically retry eventually

#

the other option is like what i mentioned - use Stripe Elements. You can probably show this immediately upon customer login to your app

#

Otherwise like what you mentioned, you can probably also redirect the user to the Customer Portal to update their card details. I'm not sure if it'll charge immediately either, but again, if you've configured automatic retries, if the limit for retries hasn't been reached, it should work out eventually

echo rune
#

I'm not 100% certain if the new card will be charged immediately once it's been provided

#

This doesn't happen

#

I mean it will not try to charge immediately

valid grove
#

ah, sorry to hear that then, i guess it looks like using Stripe Elements might be the way to go then

echo rune
#

if you've configured the subscriptions to retry if payments fail, it'll automatically retry eventually
We have enabled this feature but we won't know when the retry will happen. So we need a way to unblock the user in this case. This is what I am trying to find out

#

I haven't worked with Stripe Elements

#

But in any case, this is also documented in API documentation, right?

valid grove
#

give me a sec to find the page, my connection is a bit slow today

echo rune
#

No hurry at all. Thank you for your support

valid grove
echo rune
#

It's loading for me

valid grove
#

something i want to add on, if you decide to go with this, remember to include setup_future_usage : 'off_session' when you confirm the card payment, so that the card will be automatically attached to the customer

echo rune
#

Great, so will this be used in the future payments?

#

I like to make it default

valid grove
echo rune
#

Great, just what I needed. I think I have some research and tests to do now with the information you provided.

valid grove
#

great! let us know if you run into any issues!

echo rune
#

Sure, thank you @valid grove for the help as always.

#

Have a nice day ๐Ÿป

valid grove
echo rune
#

I'll look into these as well. Thanks again ๐ŸŽ‰

trail vale
#

@echo rune just curious, why is important to charge the customer immediately and not eventually?
Do you restrict their access until their subscription payment is in good standing?

echo rune
#

Yes, we need to restrict them from doing any actions until they complete the payment.

In our scenario, we allow the user to create the subscription without any payment information. In the beginning, it will be on trial for about 14 days. We allow the user to enter their payment info in our system (using Stripe customer portal) in the trial period.

When the trial is finished and the Stripe tried to charge the customer, if the customer does not have a payment source we don't want to allow them to use the app unless they add a proper payment source and we are able to charge immediately

trail vale
#

Ok so in your case, if you wait for their subscription to be eventually charged, you'd have the scenario where they've:

  • added a new card
  • but their subscription payment hasn't been made
  • so they'd still be restricted in the app
echo rune
#

Exactly, we don't want the customer to feel like, Hey I added the card and why am I still blocked scenario

trail vale
#

Yeah makes sense, thats a crappy experience

#

I ask because I wrote some code recently to handle updating the customer's default payment method when they add a new card

#

Initially I was unaware it was a two step process, I forgot that adding a card is only step one, step two is the customer update call

echo rune
#

I ask because I wrote some code recently to handle updating the customer's default payment method when they add a new card

#

Yes, I asked about this in an earlier discussion

#

Apparently, Stripe doesn't make it default

trail vale
#

This third step seems like a natural next thing to check for

echo rune
#

We have to manually call the API

trail vale
#

Yep yep, thanks for sharing more info, appreciate it

echo rune
#

No worries. Happy to share the knowledge ๐Ÿ‘ผ

trail vale
#

Im guessing once the customer has that fresh valid payment method attached, you could look up the invoice of that subscription and call invoices.pay

#

@valid grove that would work right?

valid grove
#

if you confirm the underlying PaymentIntent using stripe.confirmCardPayment, the corresponding invoice will automatically be marked as paid as well

trail vale
#

But if you just add a new payment method and set is as the customers default, that wouldn't update the invoice right?

valid grove
#

if you just add a new payment method and set it as the customer's default, no it wouldn't immediately attempt to charge. If you have automatic retries, then when the Stripe attempts payment again, it would automatically attempt to charge the new payment method set as the customer's default

trail vale
#

Ok thanks for clarifying

#

So same as before, Stripe will eventually mark the invoice as paid when the next payment attempt kicks in, but in between that, the customer could have added a new valid payment method but be restricted from using the app because feature access is tied to a subscription being in good standing