#Jonah Librach
severe galleon
worldly moat
Your have amount_due and status_transitions.finalized_at
hot anvil
I thought finalized at was the date the invoice was finalized, aka created
soft skiff
👋
hot anvil
amount_due has nothing to do with the date
soft skiff
If you want the specific time the payment failed then you want to actually look at the Charge
worldly moat
Hm, not sure, finalized is when it's ready to be billed
soft skiff
So you go from Invoice --> PaymentIntent --> Charge
hot anvil
Okay thanks.
So I have 2 options in my use case
- the user manually retries payment
- stripe will auto-retry payment (or just try payment for auto-subscription renewal)
Is it possible to pass metadata into the Invoice.pay command such that when the webhook is received I know which case it is?
Because if its the manual attempt I can pass a timestamp so I won't need to fetch all the info from where you said
soft skiff
Hmmm no no way to pass metadata to /pay
soft skiff
But you could update the Invoice with metadata immediately after
To achieve a similar idea
hot anvil
So I was looking at potentially just using the "date" the webhook is delivered
Intuitively, this would do as described... but webhooks_delivered_at date is before the status_transitions.finalized_at date
Maybe I just get UNIX time and be done with it
soft skiff
Yeah all depends on what you want really
hot anvil
Okay, so for some reason the created timestamp in the webhook payload is not in sync with the testclock
That's essentially giving me ~UNIX~ time
soft skiff
Yeah that is expected. Test clocks aren't really meant to test specific time of webhooks.
Like they will fire the webhooks, but the actual created date won't necessarily align
hot anvil
Okay, looking to charge --> created atm
created doesn't work here either
ch_3N8nH1EqrfgopYnc1XSbn4fj
Gives me UNIX time, not the time with my testclock
Need to go into paymentIntent?
soft skiff
Right all of these objects are going to give you the actual time as their created when using a test clock.
I don't understand
What is the issue?
hot anvil
So I'm on a testclock and I'm trying to get the testclock time the request-failed
The payment request failed
And all of these requests are giving me times that are not the testclock time
soft skiff
Why do you need "the test clock time"?
hot anvil
So that I get the expected output for the test
T
But the created is inconsistent.
The invoice.created gives the testclock time, but the evt.create (where evt is webhook payload) and charge.created gives real time
soft skiff
Okay, Yeah test clocks aren't designed for this type of specific testing. They simulate things happening like events being fired and whatnot. They don't manipulate every piece of data perfectly for every object. You can simulate invoice.payment_failed without a test clock though or you can mock responses for your test.
You are already using the right test card. Just trigger a payment without using a test clock using that card
The behavior here would be the same regardless of whether you trigger the charge manually (use /pay endpoint) or it is an automatic payment via an auto retry
hot anvil
Okay thank you.
Another question:
If I call Invoice.pay and it returns no errors, should I expect this to be a success all the way through (assuming no charge disputes)?
In other words, if I don't get an error, should I assume I'll be getting an invoice.paid webhook?
soft skiff
As long as you are using a synchronous payment method type then yes
For instance, if using a card, then yes.
That said, I'd recommend just checking the status on the response instead of relying on no error
hot anvil
What's an asynchronous payment type
soft skiff
Bank debit
hot anvil
Kk thanks, looking into this.
soft skiff
👍
hot anvil
Just saying, sometimes you just know when the person on this support knows what they're talking about
You definitely do
Appreciate the prompt responses and how knowledgeable you are
soft skiff
Happy to help and appreciate the kind words.