ChrisG AtoB - issuing reverse authorizations

[grave oracle]

Hi 👋

Can you share the transaction ID?

[cold mirage]

ipi_1KC4xfJUU4vq0xoeMG7v9uWA

[grave oracle]

Thanks!

This authorization was created back in Dec 2021

And so was the transaction

[cold mirage]

I know, it's just an example. We have a lot of these

[grave oracle]

Well the authorization is generally a response to an attempt to charge a card.

[cold mirage]

Here is one from 10/2 ipi_1LosZjJUU4vq0xoepwolFVuz

I know that. But a transaction should be representing a captured authorization, not a reversed one.

The tooltip for the reversed status on an authorization even says this

We can obviously handle for this scenario but we need to know it's an expected flow (captured transaction but then reversed authorization)

Transaction was also created nearly a day after the auth was reversed

[grave oracle]

Okay so from the records perspective the created and reversed authorization are the same record, with separate events logged against it.

[cold mirage]

I'm referring to created transaction vs reversed authorization (different records)

[grave oracle]

Right and what I am saying is that the transaction is linked to the authorization (which is both approved & reversed)

[cold mirage]

Right, and that's an expected behavior?

What does that look like on the books in regards to our account balance? If a transaction is recorded but the auth is reversed is there a balance transaction somewhere that shows this similar to a refund?

[grave oracle]

I am sorry to say I am not well versed in how that will impact your account balances. We are focused on our public API integrations and it is difficult to piece together the order of operations here based on these records. I recommend writing into Support as they have people who are more well-versed in the Issuing workflows https://support.stripe.com/contact/email