Acceptance analyticsPublic preview
Understand what affects card payment acceptance and the reasons behind payment failures or declines.
Public preview
Payments analytics is in public preview. If you’re interested in trying it, you can join the waitlist.
Use the Acceptance page in the Stripe Dashboard to analyze your payment success rate and authorization rate to identify where exactly payments fail, why they fail, and how to use this information to increase your revenue.
To go to this page, click Payments > Analytics > Acceptance in the Dashboard.
The Acceptance page in the Dashboard provides the following data for card payments:
- Payment success and network authorization rate (view as either raw or deduplicated)
- Pivot charts for common dimensions (also available as filters)
- Reasons for failed payments (authentication issue, blocked, or card network decline reasons)
- The uplift provided by Stripe’s payments optimizations features
Available data
Data on this page includes attempted and authorized card payments.
Attempted payments | An attempted payment is when Stripe sends the charge details of a customer’s attempted payment through card networks, like Visa, Mastercard, or China UnionPay. Then, the card networks send the requests to the applicable card issuing banks, who either authorize or decline the payments. A payment attempt can fail at multiple stages, even before a payment is sent to the card network. For example, it might fail 3D Secure authentication or get blocked by Stripe Radar. After the payment is sent to the card network, issuers can decline it for several reasons, such as insufficient funds on the card account or incorrect card information. Occasionally, issuers incorrectly decline legitimate payments for suspected fraud. |
Authorized payments | An authorized payment means the card issuing bank has validated the customer’s card details and reserved sufficient funds for the transaction. The payment is approved, securing the amount, but funds are not transferred until the transaction is captured by your business. Authorized payments don’t take into account whether the payments were ultimately captured. Learn more about the distinction between authorization and capture. |
Configure your data set
The filters at the top of the Acceptance page apply to all metrics, charts, and tables on the page. Stripe processes your data daily starting at 12:00 am UTC and ending at 11:59pm UTC. All data shown is in the UTC time zone.
Filters at the top of the Acceptance page.
Specify currency
If you don’t apply a currency filter, all payments appear in your default settlement currency, regardless of the actual payment currency. If you apply a currency filter, only payments made using the selected currency appear. For example, if your default currency is USD, but you select the EUR currency filter, you see only transactions made in EUR, excluding transactions made in other currencies, such as USD.
To change the currency, click + More filters > Currency, and select the currency you want from the list.
Specify account type
If you use Organizations, you can see the acceptance analytics for each account:
- In the Dashboard, click the account picker, and select your organization.
- To open the Acceptance analytics page, go to Payments > Analytics.
- (Optional) If you want to view analytics specific to a single account, under the filters, click Account, and select an account.
- (Optional) By default, the acceptance analytics for Organizations are displayed in USD. To change the displayed currency of your data, click the Show in USD dropdown, and select the currency you want. Note that the displayed currency setting is different from the currency filter.
Specify processor
Use the processor filter to display acceptance analytics based on the payment processor. Depending on your configuration, you might accept payments from processors (such as Worldpay or Adyen) in addition to Stripe.
To specify the processor, click Processor, select the processor, and click Apply. You can select and combine what processors to view based on your configuration.
Specify Connect
Connect platforms see direct charge activity aggregated across all of their connected accounts. Data from Standard accounts is only visible to platforms if you enable Platform controls.
To include connected accounts data, click Include connected accounts. To exclude, click Don’t include connected accounts.
Specify payment success or authorization rates
Use the rate filter to review your analytics using the payment success rate or authorization rate.
- To specify payment success rate, click Payment success rate.
- To specify an authorization rate click Authorization rate. If you set a processor filter other than Stripe, you can’t specify by authorization rate because Stripe doesn’t have access to their data.
The following table explains the differences between these two rates:
| Rate | Description | Types of included payment attempts |
|---|---|---|
Payment success rate | The payment success rate measures the success of all payment attempts through all stages of the payment process: 3DS authentication, Stripe or Radar blocks, and card network authorization. It’s the number of charges authorized by the card network divided by the number of unique payment attempts submitted through Stripe. We include all payment attempts except invalid API calls. |
|
Authorization rate | The network authorization rate measures the success of payment attempts that reach the card networks. It’s the number of payments authorized by the card issuer divided by the number of unique payment attempts submitted to the card network for authorization. We don’t include invalid API calls, payments that fail 3D Secure authentication, and blocked payments in the denominator because these failures occur before Stripe sends the authorization request to the issuer. |
|
The following is an example authorization rate calculation for the payment success rate and authorization rate:
| Calculation component | Component value |
|---|---|
| TOTAL PAYMENT REQUESTS TO STRIPE | 103,000 |
| Invalid API requests | (3,000) |
| Valid API requests | 100,000 |
| Failed authentication attempts | (1,000) |
| Blocked payment attempts | (1,000) |
| Total payment attempts that reach card network | 98,000 |
| Authorized payments | 93,000 |
| Payment Success Rate | 93% = (93,000 / 100,000) |
| Network Authorization Rate | 94.9% = (93,000 / 98,000) |
Specify raw versus deduplicated rates
Some payment attempts are repeat attempts of the same unique purchase. For example, if the original payment attempt is declined because the CVC is wrong, the customer needs to resubmit the payment after correcting their error. We include all attempts except invalid API requests in the calculation.
To specify the raw rate, click Raw. To specify the deduplicated rate, click Deduplicated.
The following table explains the differences between the two rates:
| Raw rate | Counts all of these attempts to make the same purchase. |
| Deduplicated rate | Groups the retried attempts together and calculates the acceptance rate based on the final outcome. |
The following table shows example calculations using a raw and deduplicated rate:
When looking at deduplicated rates, you might see a temporary drop in your success or authorization rates for the past month if not all payment retries have been attempted yet. You can also schedule repeat payment retries yourself, a practice known as “dunning," which is common for businesses with recurring revenue. If you perform dunning through Stripe Billing, Stripe highlights the affected portion of the chart using your Billing settings.
For payments through Stripe Invoices, we group attempts on the same Invoice together. For payments with Customers, we group attempts on the same Customer if they’re attempted close to each other in time and for the same amount. For all other payments, we group on the same card number for attempts close to each other in time and for the same amount.
Download acceptance data
You can download all of the data used to generate the report. Downloads provide payments that match the filters at the top of the report. The download dialog is only set to one currency filter (by default, the currency of the business).
To download these analytics, at the top of each chart click Download .
Key metrics report
This report shows the key metrics for your chosen filters, including the rate, number of authorized payments, and payment volume that was authorized. The time series compares the rate to a previous_, which you can customize. By default, the comparison period starts right before your chosen timeframe and represents the same length of time.
Payments report
The Payments report allows you to view card acceptance metrics across several common acceptance-driving dimensions. Each of the top-level filters has a corresponding pivot chart. Pairing the filtering capabilities with the pivot charts in the Payments chart provides a view that lets you monitor how different groups of payments perform over time. You can switch through each tab to compare rates, payment count breakdowns (in absolute numbers or as a share of payments), and payment volumes.
Use all of these tabs to see how changes in the rate relate to changes in payment counts or volume. You can dig deeper into any trends you want to explore with Sigma or use the itemized download to filter across available charge attributes. For example, card testing can lead to a reduction in the rate and a sudden spike in payment count.
Analyze payments across many options, such as which card brands, countries, or input methods your customers use to pay.
Card type
On average, credit success rates are higher than debit success rates, which in turn are higher than prepaid success rates. This is usually because payments made with debit and prepaid cards are more likely to be declined for having insufficient funds to complete the purchases.
Card country
Card country refers to the country of the card issuer, rather than the physical location of your customer at the time of payment. On average, domestic success rates are higher than those on cross-border payments (where the card country and your business are located in different regions). This pivot may also help you identify where your customers are based.
Processor
After you specify the processor filter, you can also view the Payments report based on processor. Depending on your configuration, you might accept payments from processors (such as Worldpay or Adyen) in addition to Stripe.
Transaction type
The card networks divide card payments into two types, depending on whether the customer is participating in the payment flow: Customer-Initiated Transactions (CITs) and Merchant-Initiated Transactions (MITs). Card issuers assign different characteristics and risk profiles to these transaction types, so there might be varying success rates between the two.
Input method
Digital wallets such as Apple Pay and Android Pay typically have higher success rates than normal online card charges because they’re tokenized and device-authenticated, creating a higher level of trust for the card issuer.
If you use Stripe Terminal, you might also see Card present as an input method option, which represents in-person payments. Industry-wide, card present success rates are typically higher than card not present ones. The physical card must be present at the time of purchase for in-person payments, so these payments often have lower risk profiles for card issuers than online payments do.
Saved card status
You can use previously saved card details to charge customers later. This is most often used for subscriptions. A saved card is also referred to as a Credential-on-File (CoF). Success rates are typically higher for saved cards than non-saved cards.
Postal code response
Address Verification Service (AVS) is an identity verification tool that allows businesses to detect and prevent potentially fraudulent credit or debit card payments by comparing the billing address provided by a customer with the billing address on-file with the customer’s card issuer, to confirm they match. Address verification is primarily supported by card issuers in the United States, Canada, and the United Kingdom.
The following table shows example values for the Postal code response metric.
| Value | Definition |
|---|---|
| Not sent | Postal code was not sent to the card networks |
| Passed | Postal code was sent to the card networks and passed validation |
| Failed | Postal code was sent to the card networks and failed validation |
| Unchecked | Postal code was sent to the card networks but no validation was performed |
CVC response
The CVC (also referred to as CVV) is the three- or four-digit verification number printed directly on a card, usually on the signature strip or the front of the card. When a card payment is submitted to a card network for authorization, Stripe sends the CVC if it is provided . Similar to AVS, the card issuer checks the CVC against the information they have on-file for the customer as an additional verification. If the provided information doesn’t match, the CVC verification check fails, which may result in a declined payment. A failed CVC check can indicate the payment is fraudulent, so review it carefully before fulfilling the order.
The following table shows example values for the CVC response metric.
| Value | Definition |
|---|---|
| Not sent | CVC was not sent to the card networks |
| Passed | CVC was sent to the card networks and passed validation |
| Failed | CVC was sent to the card networks and failed validation |
| Unchecked | CVC was sent to the card networks but no validation was performed |
Network token usage
A network token (NT) is a non-sensitive, 16-digit numeric substitute for a “front-of-card” number also referred to as a primary account number (PAN). When paired with a cryptogram, a network token can be sent to the card network in the authorization message instead of a PAN.
Unlike PANs, network tokens are payment credentials that can be dynamically restricted to specific businesses and channels, reducing the risk and impact of potential security breaches and intrusions. Businesses also use NTs for authorization rate uplift; networks contain the latest mapping between NTs and PANs, so Stripe can continue to use the same NT even if the underlying PAN changes, and avoid declines on legitimate payment attempts.
Further analyze “other”
For dimensions with several options, the pivot chart will include an “other” category to group the low volume data points that aren’t represented on the chart. For example, you might want to see the full set of card issued countries in your data. To do so, you can view the data in Sigma or download the data.
Failed payments
Use this chart to find out why payments failed or declined.
Before the payment is sent to the card network
The following sections describe failures that occur before the payment is sent to the card network.
| Reason | Description |
|---|---|
Authentication failed | You can request payments authentication with 3D Secure (3DS) using the API or with a Radar rule. Stripe might also trigger 3DS to comply with certain regulations, such as Strong Customer Authentication (SCA) requirements in Europe. The failed authentication payment requests represent situations where the customer didn’t finish the steps for authentication or failed the authentication for other reasons. To learn more about authentication failures, see Payments analytics. |
Block payments by reason | Stripe Radar blocks high-risk payments, such as those with mismatched CVC or postal code values. This automated fraud prevention product evaluates each payment, without requiring any action from you. The blocked payments represent those blocked by Stripe, obtaining initial authorization from the card issuer but refrains from charging the card. This precaution helps prevent potential fraudulent payments that might lead to disputes. See the Blocked payments by reason section below for more information. |
After the payment is sent to the card network
The following sections describe failures that occur after the payment is sent to the card network.
Issuer declines
When a payment request is submitted to the card issuer, they use automated systems and models to determine whether to authorize it. If the issuer declines a payment, Stripe shares the reason the issuer gave for the decline. In some cases, the issuer provides specific reasons for the decline with a decline code. However, many payments are categorized into generic declines (the most common of which is do_). Card issuers can only discuss the specifics with their cardholders, not with you or Stripe, for privacy and security.
For most businesses, the most common decline reasons provided for issuer declined payments fall into a few categories. Below are explanations and recommended actions to take for some common network decline reasons:
| Reason | Description |
|---|---|
| Insufficient funds | The account doesn’t have sufficient funds to cover the payment amount at the time of authorization. Prompt the customer to try a different payment method, or obtain approval from the customer to retry the payment at a later date. |
| Do not honor and other generic responses (such as Generic decline or Service not allowed) | The issuer has chosen not to provide the specific reason for their decision. Prompt the customer to contact their card issuer for more information, or to try a different payment method. Retrying the payment yourself might also be successful. |
| Incorrect number, incorrect CVC, and other incorrect card information responses | The customer has entered incorrect card information or card information that’s no longer valid. Make sure you have automatic card updates enabled. Contact the customer through multiple channels, such as email, text messages, or in-app notifications to re-enter their payment details or contact their card issuer if problems persist. Otherwise, try a different payment method. |
| Transaction not allowed | The issuer has declined the payment for unspecified reasons, which might be related to the card, or might be payment-specific. In the latter case, the merchant spend category might not be allowed on the card for example (such as FSA cards for ineligible items). The customer must contact their card issuer for more information (retries are unlikely to be successful until the issuer has been contacted), or try a different payment method. |
| Lost card or Stolen card | The customer has reported the card as either lost or stolen. Retries won’t be successful, and the customer must contact their card issuer for more information. Don’t report the specific reason to the customer in case the legitimate cardholder isn’t the one attempting the purchase. |
To learn more about the full list of potential reasons why card issuers decline payments, see decline codes.
Blocked payments chart
Use this chart to learn why some payments were blocked.
Rule match - Radar
Some payments are blocked because of a rule that you configured in Radar. This doesn’t include payments that Radar blocked by default because of their risk score.
Post authorization rule match - Radar
Some payments are blocked after the card issuer has authorized the payment because of a configured rule in Radar. Specifically, Radar rules that require a response from the card issuer, such as ensuring postal code or CVC match what the card issuer had on-file. This doesn’t include payments that Radar blocked by default because of their risk score.
High risk - Radar
Some payments are blocked by Radar by default because of their risk score. Radar determines this score using AI, and you can adjust the minimum score that it blocks by default. There are some Radar rules that block payments after they have been authorized.
Stripe
Some payments are blocked by Stripe for other reasons not included above. For example, the payment was initiated by a card on deny-lists that are globally known to be fraudulent, or a payment made from sanctioned countries. Additionally, Stripe may block payments that are suspected to be connected to card testing.
Payments optimization chart
Stripe’s solutions to increase authorization rates aim to help prevent legitimate charges from being declined. These features include Adaptive Acceptance, card account updater, and network tokens.
Note
Optimization calculations are estimates and aren’t guarantees of any outcomes. The data we provide is intended to help you inform your decision-making, in order for you to make your own independent determinations about whether to use these features. The calculation methodology for estimated impacts is also subject to change without prior notice. Refer to this page regularly to ensure you have the latest understanding of the estimated optimization feature benefits.
Adaptive Acceptance
If Stripe receives a decline response from the issuer, AI models immediately evaluate if Stripe should retry the request, and how to adjust the authorization request to improve the likelihood of acceptance. This retry request happens in real time before Stripe returns a charge response to you. The uplift shown in this report is from payments that Adaptive Acceptance successfully retried after an initial issuer decline.
Card account updater
Card numbers and expiration dates regularly change, so outdated card information is a common source of declines for online businesses. Stripe integrates with major card networks to update saved card payment information automatically to make sure you have the latest card details. The uplift shown in this report is from successful payments on cards that were updated within 180 days of the payment date.
Network tokens
Network tokens are secure payment credentials that serve as substitutes for card numbers. Network tokens ensure that you process payments with the most up-to-date credentials, because they stay current even if the underlying card data changes. Stripe has built integrations with major card networks to tokenize your cards, and AI models to determine when to use a network token to provide you the maximum success rate. The uplift shown in this report is from successful payments run with network tokens that received updates to the underlying credentials within 180 days of the payment date.