# Authorization analytics Use the _Authorization_ view in the Dashboard's _Payment lifecycle_ section to track your authorization performance over time and review your authorization analytics. This can help you to identify: - Issues that may negatively impact your sales - Opportunities to [optimize your overall payment performance](https://www.checkout.com/docs/payments/optimize-payments.md) To access your authorization analytics in the Dashboard: 1. Sign in to the [Dashboard](https://dashboard.checkout.com/). 2. Go to _Payments_ > _Analytics_ > _Payment lifecycle_. 3. Select the _Authorization_ tab. You can use the Analytics Assistant on the authorization analytics page to: - Translate natural language into SQL queries for data filtering. - Ask questions about your authorization performance. - Retrieve data across the entire payment lifecycle. - Generate charts. --- ## Authorization success rate When you request a payment, the bank that issued the payment card runs several authorization checks to determine whether to approve or decline the payment. The issuer checks if: - The card details provided are tied to a real bank account. - The bank account contains sufficient funds to cover the payment amount requested. - There are any restrictions in place on the cardholder's account. Your _Authorization success rate_ is calculated using the following formula: `number of successfully authorized payments / total number of payments submitted to the card network for authorization` Your authorization success rate is a key indicator in your overall payment performance because you can only capture funds from successful authorizations. > **Information** > > Due to differences in the way payment services providers (PSPs) calculate their authorization rate, use our [acceptance rate](https://www.checkout.com/docs/business-operations/monitor-payment-performance/acceptance-analytics.md#Acceptance_rate) for comparison instead when you benchmark PSP performance. --- ## Authorization failures If authorization fails, you receive a decline code which describes the reason for the failure. Common failure reasons include: - The customer has insufficient funds in their account to complete the transaction. - The customer entered incorrect or expired card details. - The issuer suspects fraud or flagged suspicious patterns. For example, the card may have been used for several high-value purchases at different locations within a short period of time. - The customer's account is blocked or frozen. For example, due to unpaid fees, flagged activity, or a breach of the cardholder agreement. - There are technical issues due to a network outage, or temporary issuer or acquirer issues. See the _Authorization decline insights_ view to discover why payment authorizations were declined. You can use the filters to investigate failures in specific issuing countries, issuing banks, and issuing bank identification numbers (BINs). --- ## Improve authorization rate There are several actions you can take to improve the likelihood of successful authorizations: ### Accept digital wallet payments Digital wallet payment methods typically have a higher success rate as they rely on biometric data to verify the cardholder and secure the transaction. ### Authenticate payments Implementing authentication mechanisms such as 3D Secure (3DS) or Google Secure Payment Authentication (SPA) in your payment flow can increase the credibility of your authorization rates due to their use of advanced verification processes. ### Collect important billing information Including billing information improves the credibility of your authorization request and makes the issuer more likely to accept the payment. For example, the customer's name, card number, card verification value (CVV) number, and billing address. ### Invest in reliable fraud prevention and detection tools A reputation for fraudulent activity will negatively impact the likelihood of successful authorizations. For example, if you have a high rate of chargebacks as a result of customer disputes. You can integrate with anti-fraud technologies such as our [Fraud Detection](https://www.checkout.com/docs/business-operations/prevent-fraud.md) solution to add a layer of security to your payments and help to identify and prevent fraudulent activity. ### Track response codes Learning what the response codes you receive mean can help you to understand why a payment was unsuccessful, and if reattempting is likely to result in further authorization declines. - A `20xxx` response code indicates a soft decline. Subsequent attempts may be successful. - A `30xxx` response code indicates a hard decline. The issuer or cardholder must rectify the issue before you can reattempt the payment. - A `40xxx` response code indicates a risk decline. The payment failed due to a denylist rule on your fraud prevention tool. You can also leverage [scheduled retries](https://www.checkout.com/docs/payments/manage-payments/configure-scheduled-retries.md) to reattempt a payment if it fails due to a soft decline, without any additional manual actions required. ### Use network tokens Network tokens are unique digital identifiers used to provide symbolic placeholder data across the payment flow, instead of the primary account number (PAN). They provide an additional security layer and reduce the risk of fraud because sensitive card details are only ever exposed to the card scheme and issuer. > **Information** > > You can use Checkout.com's Vault solution to [store and manage credentials](https://www.checkout.com/docs/payments/store-and-manage-credentials.md), including network tokens. ### Use pre-authorizations and split authorizations If your business model relies on capturing payments at a future date, consider using pre-authorization charges to set the optimal time and amount to charge your customers. For example, if you run a rental company, you could collect 10% of the payment upfront and 100% once the rental is complete. This can help you avoid chargebacks and refund fees. ### Use stored cards where possible Issuers have a higher level of confidence for payments performed with a card previously stored by the customer. You can leverage our Vault to store and manage customer's cards. --- ## Authorization performance The _Authorization performance_ view displays breakdowns of your authorization performance by: - Token types - Traffic types - Automatic retries - Declines - Primary and migrated merchant-initiated transactions (MITs) ### Token types The _Token types_ tab displays breakdowns of the authorization performance of transactions processed using a funding primary account number (FPAN) and those processed using a device primary account number (DPAN). An FPAN represents the cardholder's actual card number, while a DPAN represents a device-specific tokenized version of the card number typically used by digital wallets. For example, Apple Pay and Google Pay. You can see the performance of: - FPAN payments compared to DPAN payments - Network token types, by card network ### Traffic types The _Traffic types_ tab displays the authorization performance of MITs compared to cardholder-initiated transactions (CITs). ### Automatic retries The _Automatic retries_ tab displays the authorization performance of automatic retries attempted on declined payments. For example, if Checkout.com automatically resubmitted a payment request with additional data missing from the initial payment request. You can see the automatic retry outcomes by type and attempt, as well as a breakdown of the automatic retries by decline reasons and Checkout.com's success rate in recovering payments. There are two types of automatic retries: - Default retries - Typically cover standard retry scenarios. For example, Strong Customer Authentication (SCA)-related retries or FPAN/DPAN fallback attempts. - Intelligent Acceptance retries - Designed to improve success rates with more complex transactions. For example, where retry timing, routing, and optimization decisions may have a stronger impact on authorization outcomes. _Uplift via Retries_ represents the percentage-point increase in overall authorization success rate generated by retries. _First Attempt Authorization Success Rate_ represents the percentage of authorization requests that are successfully approved on the first attempt. ### Declines The _Declines_ tab displays the authorization outcomes for your highest-volume processing countries, segmented by issuing country, issuing bank, issuing BIN, or payment method. You can also see your decline trends over time, as well as a breakdown of declines by decline code. ### Primary and migrated The _Checkout.com as primary vs. as migrated MIT performance_ tab displays the performance of MIT payments in which Checkout.com was used as the primary PSP, compared to payments that were migrated to Checkout.com from another PSP. - A primary MIT is a payment that we can trace back to a previous MIT processed by Checkout.com. For example, using a `payment_id` or `scheme_id` value. - A migrated MIT is a payment that was moved to Checkout.com after previous MITs in the payment series were processed by another PSP. For example, to help recover a failed payment. --- ## Key metrics Your authorization analytics data on the Dashboard includes the following key metrics: | Metric | Definition | | --- | --- | | Amount | The total value of payments reported in the specified time frame and currency. | | Authorized payments | The total number of authorized payments in the specified time frame and currency. | | Authorization rate | The percentage of successfully authorized payments out of all payments submitted to the card network for authorization.

Calculated by dividing the number of successfully authorized payments by the total number of payments submitted to the card network for authorization. | | Count | The total number of payments reported in the specified time frame and currency. | | Decline code | A code that indicates why a payment was declined. | | Declined payments | The total number of payments that were declined during authorization in the specified time frame and currency. | | Issuing bank | A financial institution that provides payment cards (such as credit or debit cards) to consumers on behalf of card networks like Visa or Mastercard. | | Issuing BIN | The issuing bank identification number (BIN) is the first six to eight digits of a payment card number. It identifies the financial institution that issued the card. | | Issuing country | The country where the financial institution that issued a customer's payment card (such as a credit or debit card) is located. | | Payment method | The way a customer chooses to pay for goods or services.

Card payments are categorized by the card scheme (for example, Visa), and alternative payment methods (APMs) are categorized by individual methods (for example, Klarna). | > **Information** > > For definitions of other terms used throughout the payment lifecycle, see [Terminology](https://www.checkout.com/docs/business-operations/terminology.md). --- ## Related topics **[Acceptance analytics](https://www.checkout.com/docs/business-operations/monitor-payment-performance/acceptance-analytics.md)** Track your acceptance performance over time and review your acceptance analytics.