TL;DR: A declined authorizations report lists card authorizations that were refused: by the issuer and, depending on your processor, by a fraud screen. Read it for patterns, never single rows: decline rate, reason category, BIN, amount and time of day. It can expose card testing, checkout data errors and dead stored cards. It cannot show chargebacks, approved fraud, downgrades or funding problems.
The one-sentence answer: A declined authorizations report tells you why money didn't arrive at the authorization step, so it can identify card-testing attacks, data-quality errors and stale cards on file, but it can't identify anything that happens after an approval, such as chargebacks, disputes or fraud that got through.
Our decline codes guide explains what each code means. This post is about the artifact that sits one level up: a month of declines in one export, and what the patterns in it are telling you. If you need the meaning of a specific code, our credit card decline codes guide has the full list and the retry rules for each.
Prerequisites: an export of declined authorizations for a full month from your gateway or processor portal, plus the total number of authorization attempts for the same month. Thirty minutes and a spreadsheet.
What is a declined authorizations report?
A declined authorizations report is a list of authorization requests that came back refused, with the reason, amount, time, and card details for each one. Processors name it differently. One documented version, BlueSnap's Declined Auth Details report, carries 25 columns, and its core fields are a good checklist for whatever your own portal exports. The ones that matter for analysis:
| Column | What it lets you see |
|---|---|
| Authorization date and time stamp | Spikes, overnight activity, bursts within minutes |
| Authorization amount | Small-amount testing versus real orders |
| Decline reason | The issuer's reason; with the raw code, which of Visa's four categories a Visa row falls in |
| BIN number, BIN issuer, BIN card type | Whether declines cluster on one issuer or card range |
| Type of transaction / payment type | New purchase versus recurring charge versus retry or card verification |
| Shopper country, email, ID | Repeat attempts from the same customer or a burst from one country |
| Authorization fee amount | Whether you paid for the decline |
That last column surprises people. A declined authorization is still a message your processor carried, and BlueSnap's report includes an authorization fee field, left empty "if no fee was charged." Your own processor's report may not show fees at all, which is a reason to ask.
What can a declined authorizations report identify, and what can't it?
A declines report can identify problems that stop money at the authorization step: card-testing attacks, checkout fields sending bad data, stored cards that have expired or closed, issuers declining a specific card range, and retry logic hammering hard declines. It can't identify chargebacks, disputes, approved fraud, interchange downgrades or settlement delays, because those happen on transactions that were approved.
That boundary is the most useful thing to understand about this report, and it's also the answer to the certification-exam version of the question. Visa's core monitoring ratio sits on the same side of the line. The VAMP ratio counts card-not-present fraud reports (TC40) and disputes (TC15) against settled transactions (TC05), per Visa's fact sheet for the program, with thresholds effective June 1, 2025. None of those rows will ever appear in a list of declines.
| A declines report can surface | A declines report cannot surface |
|---|---|
| Card testing and enumeration attempts | Chargebacks and disputes |
| Expiry and CVV2 declines from your checkout (AVS mismatches only if your gateway declines on them) | Fraud that was approved |
| Stored cards that are expired, closed or blocked | Interchange downgrades on approved sales |
| One issuer or BIN range declining heavily | Settlement or funding delays |
| Retry loops on cards that will never approve | Customers who left before an authorization was ever sent |
If a question asks which of these is not a potential issue the report can identify, the answer is anything in the right-hand column.
How do you read a declined authorizations report, step by step?
Read the report in six passes, each answering one question. Start with the rate, then sort by reason category, then by time and amount, then by card range, then by transaction type, then by fees.
Step 1: Calculate your decline rate first
Divide declined authorizations by total authorization attempts for the same window. A declines report alone can't give you a rate, because it has no denominator. Two hundred declines is a disaster on 800 attempts and noise on 40,000.
Track it monthly. The number that matters is the change, not the level, because acceptable decline rates vary with your vertical, card-not-present share and customer base.
If your report has no approval totals: ask your processor for an authorization summary with approved and declined counts for the same date range. If they can't produce one, write that down. A processor that can't tell you your own approval rate is one of the signs you're overpaying for processing.
Step 2: Group every decline into Visa's four categories
Visa groups its decline response codes into four categories, introduced in April 2020 and set out today in Table 7-2 of the Visa Core Rules (April 18, 2026 edition). The category tells you what kind of problem a decline is before you look at the individual code. Filter to Visa rows first; Mastercard and the other networks use their own codes.
- Category 1, Issuer will never approve. Closed or lost cards, invalid account numbers (code 14) and similar. Visa's rule: the merchant "must never resubmit" for the same payment credential.
- Category 2, Issuer cannot approve at this time. Temporary conditions: insufficient funds (51), limits exceeded, suspected fraud (59), issuer or switch inoperative (91). Reattempts permitted, "up to 20 attempts in 30 days."
- Category 3, Data quality: revalidate payment information. Expired card (54), CVV2 failure (N7) and similar. Same 20-in-30 limit.
- Category 4, Generic response codes. Everything else, including 05 Do Not Honor. Same 20-in-30 limit.
Add a column to your export and tag each row. Category 2 rows are temporary, but not always the customer's money: check which codes dominate before deciding. A month heavy in Category 3 often points at stale stored cards or checkout fields you can fix. More than one Category 1 row on the same stored card means your billing system is retrying a card it should have stopped on.
If your report shows only text reasons like "Do Not Honor" with no codes: ask your processor to include the raw response code. Text labels collapse different codes into one bucket, and the category depends on the code.
Step 3: Sort by time and amount to look for card testing
Card testing shows up as a cluster: many declines in a short window, small amounts, and often the same BIN range. Visa's June 2026 merchant guidance on enumeration says "[a]ttack transactions are often less than $10 USD" and tells merchants to alert on "a large volume of approvals or declines from a similar BIN range."
Sort by timestamp and scan for bursts. Then sort by amount and look at everything under $10. A run of $1.00 or $0.50 authorizations at 3 a.m. against cards from one issuer isn't a customer having a bad day.
The same guidance flags a quieter tell: "an increase in reversals being sent," because fraudsters sometimes reverse an authorization immediately after it is approved. Reversals live in a different report from declines, so check both for the same window.
If you find a burst: turn on a CAPTCHA on every page that can submit a card, add velocity limits per IP address, device and card number, and call your processor the same day. Visa's monitoring program requires acquirers to take proactive steps to keep merchants under its enumeration thresholds: enumerated authorizations reaching 2,000 basis points (20%) of all authorizations, at a count of 300,000 or more. That gives your processor its own reason to help.
Step 4: Group by BIN and issuer
Pivot declines by issuer. If one bank accounts for a share of your declines far larger than its share of your approvals, that issuer is treating your transactions differently. Possible causes include a merchant category code that doesn't match what you sell, or that issuer's own fraud rules.
If one issuer stands out: ask your processor to confirm your MCC and to look at the issuer's response codes on those rows. Issuers generally won't discuss individual declines with a merchant, and your processor can see more of the authorization message than your report shows.
Step 5: Split new purchases from recurring charges
Filter by transaction type. Declines on first-time purchases point at checkout, fraud screening or the customer. Declines on recurring charges point at stored card data going stale, which is a billing-system problem, not a sales problem.
If recurring declines are mostly Category 1: stop retrying those cards and contact the customer for a new one. Visa doesn't permit reattempts on a Category 1 decline, and our decline codes guide covers the per-attempt fees that follow. For the recovery side, account updater services and dunning sequences, see our guide to payment recovery rates and smart dunning.
Step 6: Check what the declines cost you
If your report has a fee column, total it. If it doesn't, look for authorization fees and Visa's excessive-reattempt line on your monthly statement. Our decline codes guide shows how that line is labelled, and our walkthrough on reading a merchant processing statement covers the fee sections.
What does a healthy month look like?
A healthy month is one where you can explain the declines. The rate is stable against last month, the mix of categories is stable too, Category 3 is small and shrinking, no stored card shows repeated Category 1 declines, and no burst of small-amount declines clusters in a short window or a single BIN range.
You don't need a target number from a blog post to know if you're there. You need the same six passes, every month, and a short list of what changed.
Where does reading the report fall short?
Reading the report falls short when the data never reaches you. Some gateways decline transactions in their own fraud screen before the issuer sees them, and some processor portals show only issuer declines. If your fraud tool blocks a card-testing attack, that attack may never appear in this report at all.
When that happens: ask your processor which declines the report includes (issuer only, gateway fraud screen, or both) and get the fraud-screen rejections as a separate export. Read them together.
The report also falls short on customers who gave up. A buyer who abandoned checkout after a confusing form never generated an authorization. That lives in your site analytics, not your payments data.
Frequently Asked Questions
How far back should I pull declined authorizations?
At least one full month, compared against the month before. Some portals cap history: BlueSnap's report documents data "delayed by approximately 3 hours" and history for "the past year." Export monthly and keep your own copy so you can compare a year later.
Is a declined authorization the same as a failed payment?
Not quite. A declined authorization is the issuer, or a fraud screen, saying no. A payment can also fail before authorization (a timeout or a gateway error) or after it (a reversal, or a settlement that never completes). Only the first kind belongs in this report.
Can a high decline rate get my merchant account shut down?
Declines aren't in VAMP's core ratio, but they aren't harmless. A card-testing attack generates declines that count toward Visa's enumeration thresholds, retrying hard declines draws network fees, and your acquirer can review or close an account under its own risk policy.
Who should own this report in a small business?
Whoever owns the checkout and the billing system. It shouldn't be the bookkeeper alone, because the fixes in this guide are configuration changes on the website, in the fraud tools or in the billing system, not accounting entries.
Want a second set of eyes? We read declines reports and merchant statements as part of reviewing a merchant account, and we'll tell you which of the six passes is worth your time first. Get a custom quote.
Sources
- Visa Core Rules and Visa Product and Service Rules, April 18, 2026 edition, Table 7-2 "Decline Response Code Use": four categories and their codes; Category 1 "must never resubmit"; Categories 2 to 4 "up to 20 attempts in 30 days." usa.visa.com (retrieved October 2, 2026)
- Visa, "Updates to Rules for Declined Transaction Resubmission and Use of Authorization Response Codes" (Article ID AI10325, September 3, 2020): categories introduced April 2020, revised effective April 17, 2021 for Canada, Europe, LAC and the U.S. History only; superseded by the current Core Rules. usa.visa.com (retrieved October 2, 2026)
- Visa, "Visa Acquirer Monitoring Program Overview" (fact sheet, 2025): VAMP ratio = fraud (TC40) + disputes (TC15) ÷ settled transactions (TC05); enumeration ratio ≥ 2,000 bps and enumeration transaction count ≥ 300,000; thresholds effective June 1, 2025. corporate.visa.com (retrieved October 2, 2026)
- Visa, "Enumeration Mitigation and Considerations for Merchants," V1.3, June 2026: attack transactions often under $10 USD; alert on approvals or declines from a similar BIN range; alert on increases in reversals. usa.visa.com (retrieved October 2, 2026)
- BlueSnap Support, "Declined Auth Details Report": report columns including authorization fee amount, BIN issuer and decline reason; data delayed approximately 3 hours; one year of history. support.bluesnap.com (retrieved October 2, 2026)
ClickWerxs facilitates merchant account applications and provides ongoing account management as an authorized representative of our banking and processing partners. Approval, rates, and terms are determined by the issuing processor and acquiring bank — ClickWerxs does not guarantee approval for any merchant account application. Processing rates and fee structures cited in this post reflect publicly available industry data and general ranges; your actual rate depends on your industry, volume, and card mix. This post is not legal or financial advice. For a custom quote, see clickwerxs.com/payments/get-a-quote.
ClickWerxs is a payment processing ISO and earns a share of processing revenue from merchants it refers to its banking partners.
Kaleb Dickhaut — Founder, ClickWerxs. Kaleb built ClickWerxs from the ground up, from payment processing ISO to the Command Center platform to the AI SEO methodology the blog runs on. He has onboarded hundreds of small businesses onto payment and CRM systems. linkedin.com/in/kaleb-dickhaut