# Issuing disputes Learn how to use Issuing to dispute transactions. When an issue with a transaction occurs, a User or their cardholder can dispute the charge. Common issues include fraud, product/service not received, or processing error. Stripe offers a guided Dashboard process and an API to submit disputes and monitor them through to resolution. This process typically takes between 30 and 90 days. If you manage a low volume of disputes, we recommend using the Dashboard. If you manage a high volume of disputes, we recommend using the API. > You can’t dispute an authorization. Acquiring businesses reverse authorizations at their discretion. You can file a dispute after the authorization is complete and the acquiring business captures the transaction. ## Considerations before initiating a dispute ### Network rules We process disputes according to rules and guidelines of the card network that handled the transaction. For the complete details regarding the rules and guidelines that apply to disputes, refer to the [Visa](https://usa.visa.com/content/dam/VCOM/download/about-visa/visa-rules-public.pdf) and [Mastercard](https://www.mastercard.us/en-us/business/overview/support/rules.html) rulebooks. ### Submitting valid disputes A dispute can only be submitted once. After submission, no additional edits or supplemental evidence are allowed to be added. It’s the user’s responsibility to properly submit the dispute based on the requirements established by the card network. Filing an invalid or incomplete dispute might result in a loss. ### Consumer disputes For consumer disputes (for example, not received, canceled, not as described), cardholders are required to attempt to resolve the dispute with the business before filing a dispute. Documentation regarding the cardholder’s attempt to resolve the dispute must be included in the dispute submission. ### How Card Networks define fraud For both Visa and Mastercard, a fraudulent transaction is defined as one where the cardholder denies participating in the charge. If the cardholder acknowledges they participated in the transaction (for example a scam); they should file the dispute under a different reason for which they have dispute rights. ### Requirements for fraud disputes (for Platforms) Platforms must allow their connected accounts to submit fraudulent disputes directly to Stripe through a dashboard that you, as the Platform, make available using our APIs or embedded components. You can’t restrict their ability to submit such disputes in any way. After fraud disputes are submitted, Stripe will review them to determine if the cardholder needs to be reimbursed. ### Blocked dispute submissions Stripe might block fraud dispute submission if the transaction doesn’t qualify for fraud protection under local regulations and the account holder has no dispute rights according to network rules. > #### For platforms > > If you’re obligated to submit a dispute and you submit it, you’ve fulfilled your obligation, regardless of if Stripe blocks the submission. Card networks might consider a dispute invalid for the following reasons (among others): - The transaction is a refund and not a [capture](https://docs.stripe.com/issuing/purchases/transactions.md). - The transaction is a mobile push payment transaction. - The dispute timeframe has expired In the Dashboard, the dispute transaction button is only enabled for eligible transactions. In the API, attempting to dispute an ineligible transaction results in an error. ### Expiration Card networks establish a timeframe by which a dispute can be submitted. A dispute submitted after this timeframe is considered expired and is lost. The timeframe varies depending on dispute reason and the card network. For Visa, fraudulent and processing error disputes must be filed within 110 days of the transaction date. ‘Authorization’ disputes must be filed within 65 days of the transaction date. Consumer disputes such as ‘Canceled’, ‘Not Received’, and ‘Not as Described’ must be filed within 110 days of the merchandise or service expected at date. ### Partial amounts Disputes can be filed for the full amount or for a partial amount. If there are refunds, they must be accounted for and only a partial dispute can be filed. Certain dispute reasons, such as incorrect amount, require that only a partial dispute amount is filed. For many consumer disputes, the dispute amount is partial in cases when part of the merchandise order or service was received. ## Lifecycle In this lifecycle diagram, “business” refers to the acquiring business, the business receiving the payment. Lifecycle of an Issuing dispute (See full diagram at https://docs.stripe.com/issuing/purchases/disputes) Newly-created disputes begin in an `unsubmitted` status. At this point, you can update their evidence and metadata. After you’ve added all the required evidence, you can then submit the dispute. If you don’t submit a dispute within 110 days of the transaction clearing, its status becomes `expired`. Stripe and card networks process disputes that have a status of `submitted`. As such, you can’t update dispute evidence, but you can still update their `metadata`. Submitted disputes enter into a multi-step process defined by card networks and participating banks. After a dispute is resolved, Stripe transitions it to either the terminal `won` or `lost` status. ## Creation Fill out the **Dispute Amount** field to indicate the disputed amount (full or partial). The field’s initial value is the transaction amount. Submissions that have empty **Dispute Amount** fields create disputes with the full transaction amount. ![](https://b.stripecdn.com/docs-statics-srv/assets/dashboard-issuing-partial-disputes-amount.4e5e241c2c73428c07e60cf2e2c133bc.png) Dispute Amount field on the Issuing dispute creation page #### Dashboard Click **Dispute transaction** when viewing an eligible transaction. You’ll be redirected to a form which requests different information based on the dispute reason and product type (merchandise, services or digital goods). A dispute is created the first time you click **Save**. If you click **Submit** without saving, we create a dispute before submitting it. After you submit a dispute, you can’t modify the information or resubmit the dispute. #### API - Issuing-only Use the [Create](https://docs.stripe.com/api/issuing/disputes/create.md) method by specifying the [Transaction](https://docs.stripe.com/api/issuing/transactions/object.md) you want to dispute. You must also specify an `evidence` object whose `reason` determines its other fields. In these examples, `not_received` is populated because `reason` takes the value `"not_received"`. ```curl curl https://api.stripe.com/v1/issuing/disputes \ -u "<>:" \ -d transaction=ipi_1GW0GkKA9rkJS7vmeJlLI1Gp \ -d "evidence[reason]"=not_received \ -d "evidence[not_received][expected_at]"=1590000000 \ -d "evidence[not_received][explanation]"="Never shipped" \ -d "evidence[not_received][product_description]"="Baseball bat" \ -d "evidence[not_received][product_type]"=merchandise ``` Learn more in the following [Dispute reasons and evidence](https://docs.stripe.com/issuing/purchases/disputes.md#dispute-reasons-and-evidence) section. During creation, all evidence fields are optional for flexibility while you collect more evidence. All Issuing dispute API methods return a [Dispute](https://docs.stripe.com/api/issuing/disputes/object.md) object. #### API - Issuing with Financial Accounts for platforms Use the [Create](https://docs.stripe.com/api/issuing/disputes/create.md) method by specifying the [ReceivedDebit](https://docs.stripe.com/api/treasury/received_debits.md) you want to dispute. You must also specify an `evidence` object whose `reason` determines its other fields. In these examples, `not_received` is populated because `reason` takes the value `"not_received"`. ```curl curl https://api.stripe.com/v1/issuing/disputes \ -u "<>:" \ -d "treasury[received_debit]"=rd_1KsVPhACgxNDEoMCiKgN6Fm4 \ -d "evidence[reason]"=not_received \ -d "evidence[not_received][expected_at]"=1590000000 \ -d "evidence[not_received][explanation]"="Never shipped" \ -d "evidence[not_received][product_description]"="Baseball bat" \ -d "evidence[not_received][product_type]"=merchandise ``` Learn more in the following [Dispute reasons and evidence](https://docs.stripe.com/issuing/purchases/disputes.md#dispute-reasons-and-evidence) section. During creation, all evidence fields are optional for flexibility while you collect more evidence. All Issuing dispute API methods return a [Dispute](https://docs.stripe.com/api/issuing/disputes/object.md) object. ## Update #### Dashboard Use the **Unsubmitted** tab to access disputes that are in progress. The **Submit before** date indicates when the dispute expires. ![](https://b.stripecdn.com/docs-statics-srv/assets/dispute-unsubmitted-tab-usd.a6674be2254ad9d5fafde47eba475552.png) From the individual dispute page, click **Edit submission** to access the form where you can update the evidence. #### API The [Update](https://docs.stripe.com/api/issuing/disputes/update.md) method can be used to update the evidence and [metadata](https://docs.stripe.com/api/metadata.md) of unsubmitted disputes. For submitted disputes, only metadata can be updated. The table below describes possible updates to `evidence`. Suppose we start with `evidence` in this state: ```json "evidence": { "reason": "not_received", "not_received": { "additional_documentation": null, // We refer to these as "evidence fields" "expected_at": null, "explanation": "Not shipped", "product_description": "Baseball cards", "product_type": "merchandise" } } ``` | Action | Input | Result | | ----------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Add, replace, and remove evidence fields | ```json "evidence": { "reason": "not_received", "not_received": { // Add "expected_at": 1590000000, // Replace "explanation": "Lost", // Remove "product_description": "" } } ``` | ```json "evidence": { "reason": "not_received", "not_received": { "additional_documentation": null, "expected_at": 1590000000, "explanation": "Lost", "product_description": "", "product_type": "merchandise" } } ``` | | Change reason | ```json "evidence": { "reason": "fraudulent" } ``` | ```json "evidence": { "reason": "fraudulent", "fraudulent": { "additional_documentation": null, // Copied from "not_received" "explanation": "Not shipped" } } ``` | | Update evidence fields without supplying reason | ```json "evidence": { "not_received": { "explanation": "Lost" } } ``` | Error. The `evidence` object must always contain the `reason` field. | | Unset all evidence fields | ```json "evidence": { "reason": "not_received", "not_received": "" } ``` | ```json "evidence": { "reason": "not_received", "not_received": { "additional_documentation": null, "expected_at": null, "explanation": null, "product_description": null, "product_type": null } } ``` | ## Submission #### Dashboard The **Submit** button on the evidence form is enabled when all required evidence is present. > Review the evidence thoroughly before you submit, because you can’t modify dispute information after submitting the dispute. #### API The [Submit](https://docs.stripe.com/api/issuing/dispute/submit.md) endpoint validates that all the required evidence for the given dispute reason is present. The [Dispute reasons and evidence](https://docs.stripe.com/issuing/purchases/disputes.md#dispute-reasons-and-evidence) section provides more details. ```curl curl -X POST https://api.stripe.com/v1/issuing/disputes/idp_1GW0GkKA9rkJS7vmeJlLI1Gp/submit \ -u "<>:" ``` > Review the evidence thoroughly before you submit, because you can’t modify dispute information after submitting the dispute. ## Resolution #### Dashboard Stripe updates a dispute’s status when we hear back from the card network. If you win the dispute, its status changes to `won` and we credit your Issuing balance in the form of an `issuing_dispute` [balance transaction](https://docs.stripe.com/reports/balance-transaction-types.md#issuing_related). This balance transaction is accessible in the Dashboard under [All transactions](https://dashboard.stripe.com/balance) and on the bottom of the dispute details page. > If you make a transaction in a currency other than your account’s default currency (for example, a GBP transaction that your USD card pays), Stripe refunds the won dispute in the transaction’s original currency. If you lose the dispute, the dispute’s status changes to `lost` and we don’t credit any amount to your Issuing balance. ![](https://b.stripecdn.com/docs-statics-srv/assets/dispute-balance-transactions-panel-usd.a4e6e46b8e975afd9ff3ffd67fbcb840.png) Viewing a dispute’s balance transactions in the Dashboard. #### API Dispute statuses are updated when we hear back from the card network. If the acquiring business wins the dispute, the dispute’s status changes to `lost` and no funds are transferred. If you win the dispute, the status changes to `won` and funds are transferred back to your Issuing balance. The credit to your account takes the form of a [balance transaction](https://docs.stripe.com/reports/balance-transaction-types.md#issuing_related) of type `issuing_dispute`. The balance transaction is listed under `balance_transactions` on the `Dispute` object. However, this field isn’t returned by default. Request it using the `expand` field. See the [Expand](https://docs.stripe.com/expand.md) documentation for more details. If you make a transaction in a currency that’s different from your account’s default currency (for example, a GBP transaction that your USD card pays), Stripe refunds the won dispute in the transaction’s original currency. ## Testing #### Dashboard Stripe’s *sandbox* (A sandbox is an isolated test environment that allows you to test Stripe functionality in your account without affecting your live integration. Use sandboxes to safely experiment with new features and changes) environments allow you to test dispute logic without any live effects. For example, we send webhook events, create [balance transactions](https://docs.stripe.com/reports/balance-transaction-types.md), and update your test Issuing balance without moving any funds or changing any balances on your live account. Similar to live disputes, a test dispute transitions to `expired` 110 days after the transaction is captured. When submitting a test dispute through the Dashboard, you can choose the dispute’s outcome. Selecting **Won** automatically changes the dispute’s `explanation` field to `winning_evidence`, and selecting **Lost** automatically changes the dispute’s **explanation** field to `losing_evidence`. ![](https://b.stripecdn.com/docs-statics-srv/assets/issuing-dispute-testmode-outcome.4ecf905762fae3b734c479c7b838686c.png) #### API Stripe processes test disputes as if they’re live to demonstrate the expected behavior. For example, we send webhook events, create [balance transactions](https://docs.stripe.com/reports/balance-transaction-types.md), and update your Issuing balance. All of this happens in the seconds after you submit the dispute. In the API, submitting a test dispute with “winning_evidence” or “losing_evidence” entered into the `explanation` field informs Stripe to transition the dispute to the `won` or `lost` status respectively. Otherwise, the dispute transitions to `submitted` status as it would in live mode. Similar to live mode, a test dispute transitions to `expired` 110 days after the transaction is captured. ## Webhooks To be notified of changes to your disputes, you can listen for Issuing dispute [webhook events](https://docs.stripe.com/webhooks.md). All Issuing dispute events contain the updated [Dispute](https://docs.stripe.com/api/.md#issuing_dispute_object) object. | Webhook events | Trigger | | ---------------------------------- | ------------------------------------------------------------------------------------------------- | | `issuing_dispute.created` | Dispute created. | | `issuing_dispute.updated` | Dispute updated. | | `issuing_dispute.submitted` | Dispute submitted. | | `issuing_dispute.funds_reinstated` | Funds transferred to your Issuing balance (usually associated with `won` dispute status). | | `issuing_dispute.funds_rescinded` | Funds deducted from your Issuing balance (usually associated with a provisional credit clawback). | | `issuing_dispute.closed` | Dispute transitioned into a `won`, `lost`, or `expired` status. | ## Dispute reasons and evidence Different dispute reasons have varying requirements on what’s needed for a proper submission. Complete dispute submission and the quality of the associated documentation directly influences your chances of winning. The strongest disputes have clear, descriptive documentation. Disputes can be submitted with one of these reasons: - **Canceled**: The cardholder canceled or returned merchandise or canceled services, and the business didn’t process a credit or void a transaction receipt. - **Duplicate**: Covers processing error dispute types, including duplicate transaction, incorrect amount, and paid by other means. - **Fraudulent**: The cardholder didn’t authorize the transaction. - **Merchandise not as described**: The cardholder received the merchandise, but it didn’t match what was presented at time of purchase, or it was damaged or defective. - **Not received**: The cardholder participated in the transaction but didn’t receive the merchandise or service. - **No valid authorization**: (API only) The business processed a transaction without a valid authorization. - **Service not as described**: The cardholder received the service, but it didn’t match what was presented at time of purchase. - **Other**: A dispute scenario that doesn’t clearly qualify as any other dispute reason. Disputes submitted under this reason will be manually recategorized by Stripe. Include the actual dispute reason in the evidence explanation when filing these disputes. In the Dashboard, `Merchandise not as described` and `Service not as described` are consolidated under `Not as described`. Each reason requires a different set of evidence: #### Fraudulent | Evidence | Description | | ------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | Explanation | A description of the transaction and why the cardholder is disputing it. You can also use this field to provide an additional explanation that’s not captured anywhere else. It’s important for the cardholder to verify that they didn’t participate in the transaction, and that the transaction wasn’t made by someone known to the cardholder. | | Additional documentation | Relevant documents such as card statements or return shipping tracking. The files must be in PDF or JPEG format. Before submitting the dispute, make sure that all text and images are clear and large enough to be legible in a black-and-white fax transmission. Encouraging cardholders to keep their billing address up to date is a key component in the assessment of fraudulent disputes. | #### No valid authorization | Evidence | Description | | ------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | Explanation (Required) | A description of the transaction and why the cardholder is disputing it. You can also use this field to provide an additional explanation that’s not captured anywhere else. | | Additional documentation | Relevant documents such as card statements or return shipping tracking. The files must be in PDF or JPEG format. Before submitting the dispute, make sure that all text and images are clear and large enough to be legible in a black-and-white fax transmission. | #### Not received | Evidence | Description | | ------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | Product type (Required) | A selection of whether the purchase is merchandise, a service, or digital product. | | Product description (Required) | A detailed description of the purchase. | | Expected at (Required) | The date the cardholder expected the purchase to arrive or date of scheduled service. | | Explanation | A description of the transaction and why the cardholder is disputing it. You can also use this field to provide additional explanation not captured anywhere else. | | Additional documentation | Relevant documents such as card statements or return shipping tracking. The files must be in PDF or JPEG format. Before submitting the dispute, make sure that all text and images are clear and large enough to be legible in a black-and-white fax transmission. | #### Duplicate | Evidence | Description | | ------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | Cash receipt* | Receipt of the cash transaction. | | Check image* | Image of the front and back of the check. | | Original transaction* | The original transaction’s token that paid for the purchase. The original transaction date and amount should match the disputed transaction’s. | | Card statement* | Card statement containing the transaction. | | Explanation | A description of the transaction and why the cardholder is disputing it. You can use this field to provide an additional explanation that’s not captured anywhere else. | | Additional documentation | Relevant documents such as card statements or return shipping tracking. The files must be in PDF or JPEG format. Before submitting the dispute, make sure that all text and images are clear and large enough to be legible in a black-and-white fax transmission. | \* You’re required to provide exactly one of the four types of dispute evidence. For Incorrect Amount disputes, a transaction receipt or other record with the correct transaction amount is required. #### Merchandise not as described | Evidence | Description | | ----------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Received at (Required) | The date the cardholder received the merchandise. | | Return status (Required) | The outcome of the return. As explained in the [Considerations](https://docs.stripe.com/issuing/purchases/disputes.md#considerations-before-initiating-a-dispute) section, the dispute is only valid if the cardholder attempted to return anything they received. | | Returned at (Required) | The date the cardholder initiated return of merchandise. Stripe validates that this date comes after the “Received at” date. | | Return description (Required) | A description of how the cardholder returned the merchandise. Name the shipping carrier and provide the tracking number where possible. | | Explanation (Required) | A description of the transaction and why the cardholder is disputing it. This field can also be used to provide additional explanation not captured anywhere else. | | Additional documentation | Relevant documents such as card statements or return shipping tracking. Images or documentation showing how the merchandise received differs from the description. The files must be in PDF or JPEG format. Before submitting the dispute, make sure that all text and images are clear and large enough to be legible in a black-and-white fax transmission. | #### Service not as described | Evidence | Description | | ------------------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Received at (Required) | The date the cardholder received the service or digital product. | | Canceled at (Required) | The date the cardholder canceled the service or digital product. Card networks automatically reject any disputes that are submitted within 15 days of the cancellation date. In these cases, submit the dispute after 15 days have passed after the cancellation date and the cardholder still hasn’t received a refund. | | Cancellation reason (Required) | The cardholder’s rationale for canceling the service or digital product. | | Explanation (Required) | A description of the transaction and why the cardholder is disputing it. This field can also be used to provide additional explanation not captured anywhere else. | | Additional documentation | Relevant documents such as card statements or return shipping tracking. Images or documentation showing how the service received differs from the description. The files must be in PDF or JPEG format. Before submitting the dispute, make sure that all text and images are clear and large enough to be legible in a black-and-white fax transmission. | #### Canceled When you’re disputing a transaction because the order is canceled and not received, use the **Not received** reason instead. The **Canceled** reason is for cases where the cardholder receives the merchandise despite canceling it, and they’re expected to prove that they returned or attempted the merchandise. | Evidence | Description | | --------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Product type (Required) | A selection of whether the purchase is merchandise or service. | | Product description (Required) | A detailed description of the purchase. | | Expected at (Required) | The date the cardholder expected the purchase to arrive or date of scheduled service. | | Cancellation policy provided (Required) | A Boolean indicating whether the business provided a cancellation policy. | | Canceled at (Required) | The date the cardholder canceled the purchase. Card networks automatically reject any disputes that are submitted within 15 days of the cancellation date. In these cases, submit the dispute after 15 days have passed after the cancellation date and the cardholder still hasn’t received a refund. | | Cancellation reason (Required) | The cardholder’s rationale for canceling the purchase. In addition, if the business provides a cancellation policy, explain how the cancellation is in line with the policy. The dispute is invalid if the cancellation isn’t in line with the policy. | | Returned at | The date the cardholder initiated return of the purchase. Stripe validates that this date comes after the “Received at” date. Required if the product type is “merchandise”. | | Return status | The outcome of the return. As explained in the [Considerations](https://docs.stripe.com/issuing/purchases/disputes.md#considerations-before-initiating-a-dispute) section, the dispute is only valid if the cardholder attempted to return anything they received. Required if the product type is “merchandise”. | | Explanation | A description of the transaction and why the cardholder is disputing it. This field can also be used to provide additional explanation not captured anywhere else. | | Additional documentation | Relevant documents such as card statements or return shipping tracking. The files must be in PDF or JPEG format. Before submitting the dispute, make sure that all text and images are clear and large enough to be legible in a black-and-white fax transmission. | #### Other | Evidence | Description | | ------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | Product type (Required) | A selection of whether the purchase is merchandise, a service, or digital product. | | Product description (Required) | A detailed description of the purchase. | | Explanation (Required) | A description of the transaction and why the cardholder is disputing it. This field can also be used to provide additional explanation not captured anywhere else. | | Additional documentation | Relevant documents such as card statements or return shipping tracking. The files must be in PDF or JPEG format. Before submitting the dispute, make sure that all text and images are clear and large enough to be legible in a black-and-white fax transmission. | ### Fraud disputes You can dispute a transaction for fraud if the cardholder claims they didn’t authorize the transaction. Before filing a dispute: 1. Confirm with the cardholder that they didn’t make the transaction in error, and that it wasn’t made by someone known to them. Transactions made by a friend or family member, for example, don’t constitute fraud for dispute purposes. 1. Cancel the affected card if submitting a dispute using the API. Filing a dispute will automatically cancel the card if done in the Dashboard. In certain situations, you can lose fraud dispute rights for a transaction: - **For card-present transactions**: A card network might automatically reject a fraud dispute because liability defaults to the issuer. - **For card-not-present transactions**: A card network might automatically reject a fraud dispute if the cardholder was authenticated during the transaction. That often happens when *3D Secure* (3D Secure (3DS) provides an additional layer of authentication for credit card transactions that protects businesses from liability for fraudulent card payments) was requested or a secured payment method like Apple Pay was used. ### Authorization disputes Each time an acquiring business processes a transaction, they must first request an authorization from the issuer. If a business captures a payment without a valid authorization, or if they did obtain an authorization but it’s expired, you can dispute the transaction. Choose the reason for dispute based on the method used to submit the dispute: - **Filing a dispute through the API**: File the dispute under the `no_valid_authorization` reason. - **Filing a dispute through the Dashboard**: File the dispute under the `other` reason and specify in the `explanation` field that you’re filing a ‘no authorization’ dispute. Authorization disputes are distinct from fraud disputes: - File a fraud dispute when the cardholder didn’t participate in the transaction. - File an authorization dispute when the business didn’t obtain a valid authorization for the transaction. Another reason for an authorization dispute is an overcapture. An overcapture occurs when the captured amount exceeds the authorized amount. When you submit an authorization dispute for an overcapture, you must adjust the dispute amount to include only the amount that exceeded the authorization. > Some Merchant Category Codes (MCCs) allow overcaptures of certain amounts or disallow authorization disputes. For details, refer to the current card network rules for your region. ## Withdrawing Stripe can only withdraw a dispute within 1 day of its submission to the card network. If you want to withdraw a dispute, contact [Stripe Support](https://support.stripe.com/contact) immediately. ## Liability for fraud (platforms in the USA) Most aspects of Regulation Z don’t apply to business-purpose cards, but Regulation Z does protect users of business-purpose cards from fraud and other types of “unauthorized card use," which means the use of a charge card by a person who doesn’t have the authority to use it. In most cases, an account holder can’t be held responsible for unauthorized use of cards linked to their account unless a reasonable investigation into the fraud is conducted. However, if the account holder has 10 or more employee authorized users, they might not qualify for this protection. When one of your users disputes a transaction because the user believes it was unauthorized, Stripe sends the dispute to the card network for adjudication (as with any other type of disputed transaction). Stripe or the card network determines who must pay for the fraud: you or the business. If Stripe or the card network determines the business is liable for the fraud, then neither you nor your user are responsible for the disputed transactions. If Stripe or the card network determines that you’re liable for the fraud, then you might be required to pay for the disputed transaction. Stripe performs a reasonable investigation into the dispute to determine whether fraud actually occurred or whether the user doesn’t qualify for protection under Regulation Z. If the investigation uncovers that unauthorized card use actually occurred and that the user qualifies for protection, then you remain liable for the unauthorized transactions. Alternatively, if the investigation uncovers that unauthorized card use didn’t occur or that the user doesn’t qualify for protection, then we hold the accountholder responsible for the disputed charges. ## Email connected accounts Issuing platforms must send regulated notice emails to connected accounts when a dispute is submitted, and again when a dispute is won or lost. [Learn more about regulated notices](https://docs.stripe.com/issuing/compliance-us/issuing-regulated-customer-notices.md). ## Use with Financial Accounts for platforms Disputes of `ReceivedDebits` on `FinancialAccounts` have a corresponding [DebitReversal](https://docs.stripe.com/api/treasury/debit_reversals.md) after the dispute is submitted.