Acceptance analytics
Understand what affects card payment acceptance and why payments fail or are declined.
Use the Acceptance page to analyze your payment success rate and network authorization rate, and view pivot reports for common criteria. You can identify where payments fail and why they fail, and use this information to help increase your revenue.
Note
Optimization calculations are estimates and aren’t guarantees of any outcomes. The data we provide is intended to help 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.
Available data
The Acceptance page includes data for attempted and authorized card payments:
Attempted payments: Stripe sends the details of a customer’s payment attempt through a card network, such as Visa, Mastercard, or China UnionPay. The card network sends the request to the card issuing bank, which authorizes or declines the payment.
Authorized payments: The card issuing bank validates the customer’s card details and reserves sufficient funds for the transaction. The issuing bank approves the payment and secures the amount, but waits to transfer funds until after you capture the transaction. Authorized payments don’t consider whether the payments were ultimately captured. Learn more about the distinction between authorization and capture.
Configure your data set
You can apply the filters to all metrics, reports, and tables on the Acceptance page. Stripe processes your data daily starting at 12:00 PM UTC and ending at 11:59 PM UTC. All data shown is in the UTC time zone.
Filters on the Acceptance page
Specify the currency
Apply a currency filter to display only payments made using the selected currency. If you don’t apply a currency filter, all payments appear in your default settlement currency, regardless of the payment currency.
For example, your default settlement currency is USD, but you apply the EUR currency filter. The transactions that display only include payments made in EUR, and excludes payments made in all other currencies, such as USD.
To specify the currency, click More filters > Currency, and select your preferred currency.
Specify the 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) To view analytics for a specific 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 Show in USD, and select your preferred currency from the dropdown. The displayed currency setting is different than the currency filter.
Specify the processor
Apply the processor filter to display acceptance analytics for a specific payment processor. Based on your configuration, you might accept payments from other processors, in addition to Stripe.
To specify a processor, click Processor, select the processor, and click Apply. You can choose to view multiple processors.
Specify Connect
Connect platforms can see direct charge activity aggregated across all of their connected accounts. To see data from Standard accounts, platforms must enable Platform controls.
- To include connected accounts data, click Include connected accounts.
- To exclude connected accounts data, click Don’t include connected accounts.
Specify the payment success rate or the authorization rate
Apply the rate filter to display analytics for a payment success rate or an authorization rate.
Example rate calculation
The following is an example authorization rate calculation for the payment success rate and the 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 the 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 the raw rate or the deduplicated rate
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 must resubmit payment after correcting the error. We include all payment attempts, except invalid API requests.
Download acceptance data
You can download the acceptance data that’s generated for your report. This data includes all payments that match the filters you selected.
To download the data, click Download at the top of each report.
Key metrics report
This report shows the key metrics for the filters you selected, including the rate, number of authorized payments, and authorized payment volume.
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.
Card payments breakdown report
This report shows the card acceptance metrics across several common criteria that drive acceptance.
Each top-level filter has a corresponding pivot report. You can pair the filtering capabilities with the pivot reports to monitor how different groups of payments perform over time. You can also analyze payments across options such as card brands, countries, or input methods your customers use to pay.
Use the tabs to compare rates, payment count (in absolute numbers or as a share of payments), and payment volume. You can see how changes in the rate relate to changes in payment count or payment volume.
You can explore trends using Sigma, or filter by available charge attributes using the itemized download. For example, card testing can lead to a reduction in the rate and a sudden spike in payment count.
| Option | Description |
|---|---|
| Card country | 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 cross-border payments (where the card country and your business are located in different regions). This pivot might also help you identify your customers’ locations. |
| 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. |
CVC response | The 3 or 4 digit verification number printed on a card, usually on the signature strip or the front of the card. When Stripe sends the CVC (or CVV) to the card network for authorization, the card issuer checks the CVC against the customer information on-file as additional verification. If the provided information doesn’t match, the CVC verification check fails, which can result in a declined payment. A failed CVC check might indicate the payment is fraudulent, so review it carefully before fulfilling the order. Example values:
|
Input method | Digital wallets, such as Apple Pay or Google Pay, typically have higher success rates than card payments 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, which represents in-person payments. Card present success rates are typically higher than card not present transactions. 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. |
| Interaction type | The card networks divide card payments into two types, based on whether the customer participates 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 you might see varying success rates between the two. Each interaction type includes granular sub-categories of interaction type entailed by this filter or pivot option.
|
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 you can dynamically restrict 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. |
Postal code response | The Address Verification Service (AVS) is an identity verification tool that lets you 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. Example values:
|
| Processor | If your configuration includes multiple processors, you can use the processor filter to view the Card payments breakdown report for the selected processor. |
| Retry status | View transactions based on whether a payment has been retried. This differs from deduplication, which is the final payment attempt and can be the first attempt with the final result. |
| Other | The Other category groups low volume data points that aren’t represented on the pivot report. 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 card payments report
This report shows why payments failed or were declined.
A payment attempt can fail at multiple stages, even before the 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 reasons such as insufficient funds on the card account or incorrect card information. Occasionally, issuers incorrectly decline legitimate payments for suspected fraud.
If you have an active Sigma subscription, click View in Sigma to access templates for the queries that represent each chart.
Before the payment is sent to the card network
Failures might occur before the payment is sent to the card network for the following reasons.
| Reason | Description |
|---|---|
Authentication failed | You can use the API or a Radar rule to request 3D Secure (3DS) authentication for payments. Stripe might also trigger 3DS to comply with certain regulations, such as Strong Customer Authentication (SCA) requirements in Europe. This failed attempt is for situations where the customer didn’t finish the authentication steps 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 payments with mismatched CVC or postal code values. This automated fraud prevention feature evaluates each payment, without requiring any action from you. This blocked attempt is for situations where Stripe blocks payments. We obtain initial authorization from the card issuer, but don’t charge the card. This can help prevent potential fraudulent payments that might lead to disputes. To learn more about the reasons for blocked payments, see the Blocked card payments report. |
After the payment is sent to the card network
Failures might occur after the payment is sent to the card network for the following reasons.
Issuer declines
Card issuers use automated systems and models to determine whether to authorize a submitted payment request. If the issuer declines a payment, Stripe shares the reason provided by the issuer. 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 is do_). For privacy and security, card issuers can only discuss specific details with their cardholders, and not with you or Stripe.
For most businesses, card issuers decline payments for the following reasons.
| Reason | Description |
|---|---|
| Generic response, such as do not honor 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. You can also retry the payment method. |
| Incorrect card information, such as incorrect number or CVC | The customer has entered incorrect card information or card information that’s no longer valid. Make sure you enabled automatic card updates. Contact the customer through multiple channels, such as email, text message, or in-app notification to re-enter their payment details or contact their card issuer if problems persist. Otherwise, try a different payment method. |
| 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. |
| Lost or stolen card | The customer has reported the card as either lost or stolen. Retries won’t succeed, 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. |
| Transaction not allowed | The issuer declined the payment for unspecified reasons, which might be related to the card or payment. If it’s the payment, the merchant spend category might not be allowed on the card (for example, FSA cards for ineligible items). The customer must contact their card issuer for more information (retries are unlikely to succeed until the issuer is contacted), or try a different payment method. |
For the full list of potential reasons why card issuers decline payments, see decline codes.
Blocked card payments report
This report shows why payments were blocked.
If you have an active Sigma subscription, click View in Sigma to access templates for the queries that represent each chart.
| Block reason | Description |
|---|---|
| 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 from sanctioned countries. Additionally, Stripe might block payments that are suspected to be connected to card testing. |