#ChrisG AtoB
modern crater
somber pumice
Looking into this for you -- I'm not sure off the top of my head
rough lynx
Looking as well. Do you have any docs of ours that you have been consulting on this? Also do you have the ID of an issuing transaction that you did not see an updated event for?
thorny plaza
ipi_1Mg6LsJUU4vq0xoeKTuZ5W37
This is the API call:
Stripe::Issuing::Transaction.retrieve(
{id: transact.external_id, expand: ["purchase_details"]},
{api_key: transact.customer.issuing_api_key}
)
we knew about needing to do this special retrieve but we were only doing it for issuing_transaction.created and then were told that the L3 data comes in later but when I went to took at the issuing_transaction.updated events we've received it only counted 1604 - we millions of transactions right now so it's indicative of us not receiving the event
rough lynx
Gotcha, still looking in to this. And was this info about the L3 data coming in later from a doc of ours?
thorny plaza
I'm trying to find out how we discovered this. I was only given the task to confirm and consume 🙂
it's specifically purchase_details.receipt is what we don't get during transcation create but appears when I retrieve it now
Generally, I suspect we'd get an update event for the object in question instead of for the transaction if one existed. For example, dispute is an expandable object in a transaction but it also has its own separate API and update events. We don't get transaction update events if the dispute changes and that makes sense.
rough lynx
Yeah, I am surprised by this behavior too if it is getting updated like this after the fact. Still having a tough time finding info on this. I have a couple of places. If that doesn't work I may need to reach out to the engineers that work more closely with this and we can make an email to track that.
somber pumice
oh, one clarification:
what we don't get during transcation create
Do you mean the initial webhook notification?
thorny plaza
Yes, when we get the initial notification we do the expand on purchase details (as it's not included in the payload) and there is never receipt data in that request
somber pumice
Ok so you're already retrieving it explicitly based on the event -- that's what i wanted to check
Because expandable fields are never in webhook payloads, but sounds like you're well aware 👍
thorny plaza
Right, we weren't doing this for update events but we didn't think we needed the purchase details. I'm in charge of fixing that but at the same time also noticed we rarely get that event.
rough lynx
It looks like I do need to follow up with the engineering team on this. Would you mind writing in an email here: https://support.stripe.com/?contact=true
And then DM me your email? You can just send your first message and mention you were talking to Pompey on Discord. That will let me grab the email and I can get back to you with what I hear from my colleagues
thorny plaza
Found the conversation and I'll also be responding in this one
Hey Ale, glad to hear. Yes, that's most likely what's happening. Our SLA to populate receipt_details with data is within 24 hours of creation of the transaction object.
This is from eakbari@stripe.com
If the SLA is 24 hours we've responded to see if we can just assume no data if it's not there after that 24 hours have passed. If so, we don't need the update event to be fired and will just schedule a job a day after we receive the initial event.