#Matt11-test-clock

1 messages · Page 1 of 1 (latest)

fair crystal
#

How can I help you?

lunar grotto
#

Hi, I'll explain to you my setup

#

I have a plan with trial period of 7 days

#

I setup a test clock with a customer and a subscription with the plan

#

I advanced time by 7days + 1 hours and I started reading the webhook log in my application

#

I attached to the subscription the payment method 4000000000000341, that is the error card

#

two weird things after the time advance:
1- the subscription status is "active"
2- the invoice is in draft

#

why?

fair crystal
#

Can you share the subscription ID?

lunar grotto
#

the test one?

fair crystal
#

Yes, the one that you're facing the issue. It should be something like sub_xxx

lunar grotto
#

sub_1L1PqLApMCw5clA3WG5jx4ny

#

the problem here is that I'm doing some stuff on my application according with the subscription status, so since it is 'active' I'm activating my user. But the payment is not really active

#

stripe says that the invoice is scheduled to be processed on may 27th, but I advanced time

fair crystal
lunar grotto
#

where did you read that?

#

I read "When the payment succeeds the subscription status moves to active", so since is not successfull I expect it isn't active

#

"The status can also become active if you offer trials that don’t require payments. When the trial is over, the subscription moves to active and the subscribed customer starts to be charged.".
How do I force the subscription to require payment?

#

my need is that during the transition from trial to active the customer is charged immediately

#

I need to do a synchronous event

fair crystal
#

I'm checking internally on how to do that

lunar grotto
#

thanks

tawdry vault
#

👋 , I'm taking over for @fair crystal, just give me a few minutes to catch up

lunar grotto
#

ok thanks

#

he was asking internally for an issue

tawdry vault
#

could you try to advance the test clock for one day please?

lunar grotto
#

ok, a moment please

#

done

tawdry vault
#

now the payment failed right?

lunar grotto
#

yep

tawdry vault
#

the idea is that after the invoice gets created it will be in a draft mode, and it will try to get finalized and paid after some time

#

the event that you should be listening to is invoice.paid instead of the customer.subscription.updated

lunar grotto
#

the problem here is that inside my application the users need to be activated when it pass from trial to active

#

I cannot let them wait 1 week when Stripe tries to pay the invoice

tawdry vault
#

yes you can do that in two steps

#

you will receive the invoice.paid event when you first create the subscription for the trial period

#

and the amount of that invoice would be 0

#

and the subscription status would be trialing

#

when the trial period ends you will get another invoice.paid or invoice.payment_failed(in your case) and you will change the status in your application accordingly

lunar grotto
#

ok

#

but

#

how much time it will pass between the end of trial and the event invoice.paid or invoice.payment_failed?

tawdry vault
#

a couple of hours normally

lunar grotto
#

it is something I can edit?

tawdry vault
#

no unfortunately

lunar grotto
#

ok, so inside my application the customer will be "not active" during the stripe delay

#

correct?

tawdry vault
#

they will still be on trial no?

lunar grotto
#

nope, because when I create my own subscription inside a database I have a from and to = from + 7 days

#

so when current_time > to the user is disabled

#

maybe I could set the to = from + 7 days + 5 hours

#

so in the meanwhile Stripe it will try to pay the invoice

tawdry vault
#

yeah that's a good idea

#

just give some buffer there

lunar grotto
#

ok thanks

#

so listening for customer.subscription.updated is incorrect?

#

because until now everything is working

#

is it luck? 😄

tawdry vault
#

yeah it was 😛

lunar grotto
#

OMG

#

thanks

#

is it possible to save this conversation?

tawdry vault
#

no but to put it in a more serious way, it was working because the payment was not declined

#

the thread does not get deleted

lunar grotto
#

where can I find it when it's closed?

tawdry vault
#

you could still search the discord for the conversation

lunar grotto
#

ah ok thanks

tawdry vault
#

or you could copy the message link

#

and save it somewhere

lunar grotto
#

thanks a lot!

#

I'm discovering a lot of new things 😄

tawdry vault
#

just bear in mind that when using test clocks you won't be able to add more than 3 subscriptions per user

lunar grotto
#

another question sorry

#

Why when I advanced time the invoice try day stayed the same? I mean I expect that also the try date changes

tawdry vault
#

it will change when you get to the retry attempt

#

the next retry is on 2022-05-29 02:01:15

#

your test_clock is still on the 28th

lunar grotto
#

yes but when I started the clock the date was 2022-05-20

tawdry vault
#

the first payment was on the 27th

lunar grotto
#

ok you're right

#

thank you 🙏

tawdry vault
#

you're welcome

#

let me know if you need any more help

lunar grotto
#

for now it's everything ok

#

I will try the new event listener

#

hey @tawdry vault I have another question

tawdry vault
#

sure

lunar grotto
#

inside my application I have the "old" logic with subscriptions and a new logic with payment_intents

#

If I change the listener to invoice.paid and invoice.payment_failed, will I receive also the event from the payment_intents?

tawdry vault
#

yes but it would be duplicated events

#

you should listen to invoice events for subscriptions

lunar grotto
#

are different events?

#

I see only one "invoice.paid" event

tawdry vault
#

I meant that when an invoice.paid is fired there will also be a payment_intent.succeeded that will fire as well

lunar grotto
#

but is a different event

#

I need to do some logic in the same moment

tawdry vault
#

exactly why I said for invoice you should only look at invoice.paid and not the payment_intent

lunar grotto
#

yes but if I have subscriptions and payment_intent I will receive events from both of them, isn't it?

tawdry vault
lunar grotto
#

I don't need to pass from webhook if it is a payment_intent

#

the webhook are required only for subscriptions

tawdry vault
#

then you don't need to listen to the payment_intent events in that case

lunar grotto
#

sorry I don't understand. when I confirm a payment_intent, stripe creates an invoice?

tawdry vault
#

invoices are related to subscriptions

#

not to one-time off

lunar grotto
#

oh ok, so for a payment_intent there will not be an invoice.paid event

tawdry vault
#

yes

#

this is why I said if you want to listen for both events the best thing to do is to ignore the payment_intent events when the invoice field on that payment_intent is not null

lunar grotto
#

right now i'm listening only for subscription.updated

#

so every invoice has the 'subscription' field filled

ornate urchin
#

yep you should listen to the invoice.* events as mentioned.

lunar grotto
#

yes thanks

lunar grotto
#

and what is the difference between invoice.paid and invoice.payment_success?

ornate urchin
#

invoice.paid happens whenever an invoice moves to the paid status, but invoice.payment_succeeded only happens if there was an actual payment charging a payment method in Stripe

#

so for example it doesn't happen if the invoice was for $0 because of coupons or stuff, so it's generally not as useful or consistent and everyone should use invoice.paid