How does an authorization work?
The customer enters card details, and the merchant’s PSP sends an authorization request through the acquirer and the card network to the issuer. The issuer checks that the card is valid and active, that the account can cover the amount, and that the payment passes its fraud models. It then returns an approval code, or a response code that explains the decline. Stripe’s documentation sums up the approved case: the bank checks for sufficient funds and holds the amount on the customer’s account to guarantee it for the merchant. Where 3-D Secure is used, the cardholder is authenticated before the authorization request is sent.
Why does authorization matter?
It is where approval rate is decided and where most lost revenue in card payments starts. As an illustrative example: an online store sends 10,000 authorizations in a month and 8,300 are approved. Of the 1,700 declines, a share are soft declines that a second route or a later retry could recover, and the rest are hard declines that should end the attempt. Reading the response code on every declined authorization is what separates the two groups.
What can go wrong?
Authorizations can time out, leaving the merchant unsure whether the customer’s funds are held, which is why each request needs a unique reference. Holds expire if the order ships late, so stores that capture at dispatch need to watch the validity window. And an approval only covers the amount and the window authorized: capturing more, or capturing after expiry, needs a new authorization, which the issuer can decline.
Where does Omno use it?
Omno sends each authorization to the PSP chosen by routing rules from the providers allowed by PSP eligibility rules, moves a rejected payment to the next PSP in the rule, records the response code for every attempt in the routing-decision log, and reports the final status by webhook.