Authorisation Rates: What You Control in the Request

Measure by decline category before changing anything

A single approval percentage hides everything useful. Visa's 18 April 2026 Core Rules group decline response codes into four categories, and the category determines whether anything can be done. Category 1 is “issuer will never approve” — codes such as 14 (invalid account number), 41 (lost card, pick up), 43 (stolen card, pick up), 46 (closed account), 57 (transaction not permitted to cardholder) and R1 (revocation of authorization order). Category 2 is “issuer cannot approve at this time”, including 51 (not sufficient funds), 59 (suspected fraud), 61 (exceeds approval amount limit) and 91 (issuer or switch inoperative). Category 3 is data quality — revalidate payment information, covering 54 (expired card or expiration date missing), 82 (negative online CAM, dCVV, iCVV or CVV results) and N7 (decline for CVV2 failure). Category 4 is generic. Split your declines this way monthly and the fixable share separates itself from the noise.

The rules require complete, accurate data

Visa's rules state that an acquirer must ensure all authorisation requests and clearing records contain complete, accurate and valid data, and that if an authorisation is obtained, the data in the subsequent clearing record or authorisation reversal must be the same as, or consistent with, comparable data in the request and response. Merchant outlet country data must stay the same throughout the transaction life cycle. A Category 3 decline is the issuer telling you the data was wrong, and it is one of the few decline reasons a merchant can genuinely fix — by revalidating the card details with the customer rather than by resending the same request.

Do not manipulate the request to force an approval

The rules are explicit on reattempts. An acquirer, merchant, payment facilitator or VisaNet processor that reattempts an authorisation request following a decline response must not intentionally manipulate any data elements from the original request, including the acquiring identifier, acquirer and merchant country, MCC, POS condition code, POS environment field, POS entry mode and electronic commerce indicator. Vendors occasionally market retry logic that varies these fields. That is prohibited, and it puts the account rather than the transaction at risk.

Flag the transaction for what it is

Mis-flagged transactions look wrong to issuers. For stored credentials, Visa requires that after a cardholder agreement is completed in writing and before the first transaction, the merchant submits either an authorisation request for the amount or, if no payment is required, an account verification — and if that initial request is not approved, the merchant must not store the credential. A transaction using a stored credential must use POS entry mode code 10, and a recurring, installment or unscheduled credential-on-file transaction must carry the appropriate indicator in the POS environment field. Getting these right is configuration work in the gateway, not a negotiation, and it is where a surprising share of unexplained declines on repeat billing originates.

Keep the credential current

A card that has been reissued will decline until the stored details are updated. Visa Account Updater exists for that: issuers in the listed regions must enrol their BINs and submit updates whenever reissuance or a change in account status occurs, with an account number and expiry change permitted only where the account number has been activated and an authorisation request using the updated data can be approved, and submitted within 2 business days of activation. VAU also carries closed-account, contact-cardholder and opt-out advices. Network tokens address the same problem from the other end: EMVCo describes an EMV payment token as a unique alternative value that replaces the PAN and is constrained in how it can be used. Ask your gateway which of the two you have, and whether both are enabled on recurring volume.

Authentication data, and the declines you cannot fix

For card-absent orders, EMVCo says EMV 3DS “enables the exchange of data, or messages, between the merchant and the issuer to authenticate the consumer and approve the transaction,” covering the transaction, payment method and device, and that flexible authentication methods help issuers judge legitimacy, which “results in increased transaction approval rates and fewer false declines.” For what remains, the rules draw the line: after a Category 1 decline, a merchant must never resubmit an authorisation request or account verification for the same payment credential; other categories permit reattempts up to 20 attempts in 30 days, which is a ceiling rather than a schedule. Where a merchant-initiated stored-credential request is declined, the merchant must notify the cardholder in writing and allow at least 7 calendar days to pay by other means. Illustrative example only, with made-up round numbers: if 1,000 recurring charges a month produce 60 declines and half are Category 1, your addressable population is 30, not 60 — which is the kind of figure that decides whether the work is worth doing.