#pepski-charge
zenith oracle
I have this charge - ch_3LZfRtCZ1pXYosAt1R5jtLKp in dashboard I can see this in the description
Payment refunded. It may take a few days for the money to reach the customer's bank account.
This refund went through in the form of a reversal.
When I call Charge.retrieve("ch_3LZfRtCZ1pXYosAt1R5jtLKp"). I received the Charge correctly
when I use Charge.list(params), the charge is not included
stuck swallow
well the charge is special because it's the result of an incident we had last month
i.e. it's one where you called the API, we returned you a 500 error on the API call, but it was processed internally. We automatically refunded it as mentioned there
so because it's an internal charge object, it's not being returned in list calls
zenith oracle
so we are not able to know about these errors at all?
We have also this case ch_3LG0CECZ1pXYosAt1o8s91Pw
created in June and refunded in August
already payouted... we are finding some solution for these cases
stuck swallow
ok well let's take it one at a time
stuck swallow
so we are not able to know about these errors at all?
what do you want to know? Where did you even find ch_3LZfRtCZ1pXYosAt1R5jtLKp from exactly?
zenith oracle
okay, sure., give me a sec
in here -
this payout po_1Le7GS2RnNFSgNACCeN9NQqv
for this account acct_1L2UmC2RnNFSgNAC
stuck swallow
ok cool
so what information do you want specifically that you don't have? Bear in mind really that it's an exceptional circumstance since we had a large outage, perfect results are not guranteed
zenith oracle
basically we are mapping our transactions according to these payouts. And in this payout is that its created from 3 transactions - but in the reality it is created only form one (because the two other are 'errors'). Our integration is failing on it, because we don't have data about this success / refund events.
We have a transaction in our system flagged as FAILED (which is correct I guess?). But in the payout you are sending me that there was a transaction and refund (which is not the same as FAILED in my dictionary). How can I determine that this is the error transaction because of some outage?
stuck swallow
you would write to our support team to mention that you noticed this inconsistency and we'd explain to you (as I have) that it's due to the outage we had that day(https://twitter.com/stripestatus/status/1561803008261758976) causing internal charges that ended up getting refunded, and you'll have to treat it specially
zenith oracle
so there is no way how to solve these 'outages' in our integration?
Why are they included in the payout info if they are just an errors?
Thats the whole point.. why are they included in the payout info, (which we are giving to our account members so they know about it).
stuck swallow
not everything can be solved in code automatically no, there's need for some manual operational work sometimes
stuck swallow
Thats the whole point.. why are they included in the payout info, (which we are ...
because our internal system that reconciles the payout to its related transactions (which is its own thing built by entirely different teams than ones involved in the APIs for working with PaymentIntents and charge attempts) must pick up those otherwise-merchant-hidden charges and they're returned in the results. Not ideal but if you're asking 'why' that's why.
you can raise the feedback to https://support.stripe.com/?contact=true about how it's confusing to get that data exposed etc and it can help prioritise changes we might make
zenith oracle
Okey i will raise a one.. I was just looking for a way how to see these 'hidden' charges. So there is no way if I am getting it right.
Because I need to pair all transactions from payout info. So I need a info about them, or I need a info that these were just errors and should be ignored in payout detail
stuck swallow
yeah but like I said, not everything can be solved in code automatically, there's need for some manual operational work sometimes . Not everything can be ideal all the time especially when we have outages . Maybe for example it would help to have some way in your system to manually mark a charge as ignorable when you determine it 's something like this.
zenith oracle
yeah, thats good a way, flag them we we receive 500.
stuck swallow
yes, as the charge in question relates to this error you would have got at the time : https://dashboard.stripe.com/logs/req_IjgFUURTi0FMKa
zenith oracle
But in case of ch_3LG0CECZ1pXYosAt1o8s91Pw it will case a troubles, because the refund by you was done 2 months later after payout.
stuck swallow
well I haven't looked at that one, as I said I was taking it one at a time
zenith oracle
sure no problem 🙂
For the first case, this flag suits good for us.
thanks for your advice
stuck swallow
that one, I don't know, you can see it 500'd in June as well : https://dashboard.stripe.com/logs/req_IjgFUURTi0FMKa It was reversed in August too the day we had the outage. Probably what happened is it got picked up by the same "API breakage" sweep we did after the August outage and reversed by that same process. Which is not ideal at all and is something you could raise with our support team as something unexpected or that your customer might have complained to you about
zenith oracle
okay so reverse after a 2 months is something really unexpected? So it should not happened at all and we are good to go with the flag 'ignore this charge because it was created with 500'?
And we can 'relay' on the thing that if the payment is created with 500 - it will be somehow solved by your side and customer will be always refunded?
stuck swallow
I wouldn't expect it to happen no
and no you can't really rely on any particular behaviour, see https://stripe.com/docs/error-low-level#server-errors and the screenshot from that page I posted a little above