#Greg00z - search API
1 messages ยท Page 1 of 1 (latest)
Good question. Not immediately sure why that may be the case. So you are using the search API for both queries or is the second call a list call?
yep I used the search for both call
one by setting disputed to false, and one with disputed to true
the first one will give many results, including one with disputed to true
the second one give me 0 result
stripe.charges.search({
query: 'customer:''<my customer id>'' AND disputed:'false'',
})
Hi there ๐ apologies for the delay. I'm jumping in to lend a hand, please bear with me a moment while I catch up on the context here.
Can you share the ID of a request where you encountered this behavior?
Awesome, thanks!
I've been able to reproduce the behavior that you're describing so far. Could you provide the ID of some charges related to this Customer, and indicate whether they are or aren't being included in the search results that you're receiving?
yes sure
one minute
py_3KjYsUKAYYjxaiGA0UKFsJeI
--> disputed false
py_3KuTJ1KAYYjxaiGA0CIVj9hp
--> disputed true
both of charges are not included in the search result, until I pass disputed to false in the query parameter
so it means there is also an issue on the other side, when I put disputed:'false', I get also py_3KuTJ1KAYYjxaiGA0CIVj9hp and py_3KjYsUKAYYjxaiGA0UKFsJeI in the result
going to dig into this a bit, but to clarify, are you definitely looking at all the results? i.e., do you paginate so you are not just looking at the first 10 returned and assuming that was all that came back?
https://stripe.com/docs/api/pagination/auto?lang=node
but I guess that's not the issue since you say you get no results. Do you have the exact request ID req_xxx for the search you make that had no results? that would help
req_EbPprCMbXrvez9
I'm experimenting with this on my account and all I see really is that doing e.g. query:"customer:'cus_MCxFnj1MF5Li1Q'" will only return non-disputed charges(I guess the query by default excludes them if disputed is not passed as true explicitly)
this is the request that returns me 0 result
and yes Im looking to get all the result, without using pagination
I mean you have to use pagination, that's not optional, if there's more than 10 results you have to use pagination.
but yeah it's weird you'd get zero results for that query, maybe it's broken for SEPA DD
I can test but will take me a while to do some test mode SEPA payments
yes but as you said, I get 0 result so there is no need to use a pagination
and for that customer, I only have 3 charges at all
yeah I mean there's definitely a bug
I'll do some testing but you should write to https://support.stripe.com/?contact=true to report it since it will take a while to investigate and track it down and follow up
ok but I started by talking with them about that issue in the chat, and they asked me to go to discord
so Im little bit confused on where to report the issue ๐
they're not supposed to tell you to come here unfortunately
they're supposed to escalate the question to teams like mine(we also answer over email)
anyway I'm testing this and can't really replicate, you can see I have a customer with card and SEPA payments and some are disputed and some aren't and I get results
yeah I really can't replicate what you're seeing unfortunately, as you can see for me, this all works as expected and returns all charges with no filter, and only disputed ones when disputed:true and non-disputed ones with disputed:false
are you sure you're definitely getting nothing and haven't misunderstood something ? unfortunately our logs don't say what we returned or how many results the search API call found so I have no way to verify what we returned without you sharing exactly your code and results, similiar to what I did in those screenshots.
@swift drum can you do await stripe.charges.retrieve("py_3KuTJ1KAYYjxaiGA0CIVj9hp") and check what's returned? is disputed:true in the response?
disputes on SEPA can be strange and what we call a Dispute in the dashboard might be more of a a declined payment in the API. This is also an old payment so maybe the data was wrong back then.
ok one minute
req_A5TYS3g8nfEXp3
--> on this request, I only put the customer query parameter, and I get 3 results
including one with disputed to true
the 2 others have disputed to false
req_QqjNDgRiWmIc99
--> on this request, I add the disputed query parameter setted to true, and I get 0 result
ok, perfect
yeah so that's unusual.
can you do what I asked in my last message here and retrieve the Payment ID that is marked as disputed in the dashboard and see what the API returns exactly? @swift drum
yeah that's weird then
I unfortunately have no idea, I set up the same data as you do(a customer with some successful and some disputed payments using SEPA and also cards), and as I posted above the filters work as expected, so I don't understand why you get no results for https://dashboard.stripe.com/logs/req_QqjNDgRiWmIc99
there must be some specific bug or broken index with that particular customer or payment, not a general API problem. You can contact our support team to try to escalate , and if you see this same sort of problem with other Customers, let us know.
(I deleted your reply just because there was personal info in it but I did see that disputed:true is set on the Charge object)
ok, so I need to talk again on the support chat ?
I would send an email instead really summarising what we found here : share the request ID that returns no results, the customer ID, and mention you spoke to me
its the only customer that we have with a dispute, so I started today to code a solution to automaticly prevent the customer, by using the stripe api
and I faced immediatly the issue with the charges search api
I thought it was a real bug in stripe api
what is the email ?
https://support.stripe.com/?contact=true and pick the email option in the popup
maybe it can help to resolve the bug, if I put the disputed query parameter to false, it returns me all the charges, with disputed to false and true
so it's like stripe consider all the charges with disputed to false
yeah it's strange, that's not what I see exactly when testing but clearly something is a little unusual in your case.
alright, I sent an email though the support with all the details