Authorization analytics
Last updated: April 1, 2026
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
To access your authorization analytics in the Dashboard:
- Sign in to the Dashboard.
- Go to Payments > Analytics > Payment lifecycle.
- Select the Authorization tab.
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 for comparison instead when you benchmark PSP performance.
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).
There are several actions you can take to improve the likelihood of successful authorizations:
Digital wallet payment methods typically have a higher success rate as they rely on biometric data to verify the cardholder and secure the transaction.
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.
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.
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 solution to add a layer of security to your payments and help to identify and prevent fraudulent activity.
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
20xxxresponse code indicates a soft decline. Subsequent attempts may be successful. - A
30xxxresponse code indicates a hard decline. The issuer or cardholder must rectify the issue before you can reattempt the payment. - A
40xxxresponse code indicates a risk decline. The payment failed due to a denylist rule on your fraud prevention tool.
You can also leverage scheduled retries to reattempt a payment if it fails due to a soft decline, without any additional manual actions required.
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, including network tokens.
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.
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.
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)
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
The Traffic types tab displays the authorization performance of MITs compared to cardholder-initiated transactions (CITs).
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.
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.
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_idorscheme_idvalue. - 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.
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.