Yes, in the case of 2-step transactions, the first step is Authorization(program receives a JIT funding request for this authorization followed by a webhook notification) and the second one is a clearing(program would receive a webhook notification for this clearing ). The authorization is always associated with a gpa.credit.authorization event.
If the customer chooses to cancel this authorization at the POS , we would typically receive an authorization.reversal event (program would receive a webhook notification for this) and what this event does is , it releases previous hold that was placed on the authorization amount on our end. Upon receiving the authorization.reversal webhook event , the program is expected to release the previous authorization hold on their end as well. The authorization reversal is always associated with a gpa.credit.authorization.reversal.
The authorization or the associated gpa.credit.authorization event would be in "declined" state only when the authorization fails due to various reasons like invalid pin , expiry mismatch, card/cardholder state , auth restrictions , velocity controls etc. When authorization goes through successfully and the customer decides to cancel it at the POS , the authorization would not be in declined state .
Here is some helpful documentation regarding ledger impact for various transaction event types : https://www.marqeta.com/docs/developer-guides/ledger-management-with-jit-funding#_ledger_impacting_t...
Hope this helps!
