# Chargeback response deadlines: work from the live case, not a day count

[By Evidenz](https://evidenz.dev/)  5 min read

There is no single response deadline for every chargeback. Use the date and time on the current processor case, preserve its timezone, and distinguish a saved draft from submitted evidence. An internal review cutoff should leave time to fix rejected files or a failed submission.

A chargeback response deadline is the cutoff for submitting a response to a specific dispute through your payment provider. It is not the deadline for the customer to start a dispute, or the date by which the issuer must decide it. Open the live case before planning the work: a familiar number of days is not a safe substitute for its actual due date.

## Is a chargeback time limit the same as a response deadline?

No. A customer's filing window, your provider's evidence deadline, and the issuer's review period describe different events. An article about how long a cardholder has to dispute a payment does not tell a SaaS team how long it has to respond to the resulting case.

Keep the current case's deadline as the operating value. A later [pre-arbitration notice](https://evidenz.dev/articles/chargeback-pre-arbitration) also needs its own stage, requested action, and provider instructions; the original response date should not be reused.

## Capture the deadline with the case identifier

Record the dispute ID, disputed payment, current status, response deadline, and the time you checked them. Assign one owner who can submit through the relevant provider account, plus a backup who has the necessary access.

[Stripe describes a limited response window that varies by card network.](https://docs.stripe.com/disputes/responding) Its API example exposes the case deadline as [`evidence_details.due_by`](https://docs.stripe.com/disputes/api). Use that case value rather than adding a standard interval to an email notification. A notification might be read late or forwarded to the wrong team.

Keep the provider account in the record as well. A business with several accounts can have a correct dispute ID and still send its reviewer to the wrong dashboard. An alert should open the specific case and show who owns the next action.

Deadline fields differ across systems. [Checkout.com's dispute API exposes `evidence_required_by` alongside the payment and case data.](https://api-reference.checkout.com/tag/disputes) A cross-provider queue should retain the source field and case identifier when presenting a common deadline column. Do not manufacture one default interval for records from different processors.

## Make the time unambiguous

A calendar entry saying “Friday” leaves several questions unanswered. Which timezone? At what time? Is the displayed date already converted for the person viewing the dashboard?

For a timestamp supplied by an API, retain the original value and show an explicit UTC representation alongside the reviewer’s local time. Label the timezone on exported task lists and handoffs. Do not silently interpret a Unix timestamp in milliseconds when the provider supplies seconds.

**Illustrative example.** A provider gives a cutoff of November 6, 2026, at 17:00 UTC. That is 18:00 in Berlin on that date. An internal review set for 17:00 Berlin time leaves only one hour; it does not leave a whole business day. The example illustrates conversion, not a provider’s standard cutoff.

If a dashboard gives only a date, check its help text or ask the provider how that date is interpreted. Do not invent midnight as the cutoff. Daylight saving changes make fixed offsets particularly unreliable for recurring calendar rules.

## Separate preparation from submission

Use distinct work states: investigation underway, evidence ready for review, approved for submission, and submission confirmed. A document saved in a shared folder only establishes that a document exists.

Set the internal review cutoff earlier than the external deadline. The buffer is an operational choice based on your staffing and submission process, not a card-network rule. Allow time for a reviewer to spot an incorrect charge, missing attachment, unreadable export, or upload error.

Provider workflows differ. [Shopify Payments documents automatic submission of available response data on the due date.](https://help.shopify.com/en/manual/payments/chargebacks/resolve-chargeback) A team using that workflow should still review what will be sent. Do not assume the same behavior exists in another processor account or in a custom integration.

## Keep customer conversations on a separate track

A customer may be discussing a refund or [withdrawing the chargeback](https://evidenz.dev/articles/withdrawn-chargeback) while evidence is being prepared. Record those conversations, but keep the response task open until the live case and provider instructions justify closing it.

A promised reply from the customer does not extend the submission window. If the evidence remains incomplete, the owner needs to make the accept-or-challenge decision in time, rather than letting a support conversation make that decision by accident.

## Verify what the provider accepted

After submitting, reopen or retrieve the case. Retain the confirmation, case status, submission time, and the evidence version sent. For an API workflow, distinguish a successful upload of a file from successful submission of the dispute response.

If a request fails or its result is unclear, inspect the current case before retrying. Avoid relying on a local “sent” flag alone. A task should only become complete when its state is supported by the provider’s record.

When a deadline has passed, check the actual status and available support route. Do not promise that a late attachment or a customer email will reopen the case. Preserve the failure details so the next review can fix the missed handoff, notification, or submission check. The broader [response guide](https://evidenz.dev/articles/respond-to-chargebacks) explains how to choose evidence; this workflow makes sure that decision reaches the case on time.

### Give the case owner a usable history

Evidenz is designed to help B2B and B2C SaaS teams understand the customer history they need to review before the response window closes. Billing, support promises, account changes, and relevant activity belong in an investigation linked to the account, with open questions stated plainly. The benefit for the owner is a handoff that explains the proposed response and its supporting records, instead of another request to search across systems. The provider’s current deadline and submission confirmation remain the operational facts on which the team acts.

## Sources and scope

Sources checked October 2026

Published by Evidenz. Examples are illustrative, not customer results. Check current requirements and the actual case against the linked sources.

- [Stripe: Respond to disputes](https://docs.stripe.com/disputes/responding)
- [Stripe: Use the API to respond to disputes](https://docs.stripe.com/disputes/api)
- [Shopify: Resolving a chargeback or inquiry](https://help.shopify.com/en/manual/payments/chargebacks/resolve-chargeback)
- [Checkout.com: Disputes API reference](https://api-reference.checkout.com/tag/disputes)

Customer context is our starting point.

Evidenz is being built for B2B and B2C SaaS: a shared customer history across subscription billing, accounts, support, and digital product activity. Join the waitlist for early-access news.

[Join the waitlist](https://evidenz.dev/#hero)

## Keep reading

[6 min read

### How to respond to a chargeback, with a SaaS rebuttal letter example](https://evidenz.dev/articles/respond-to-chargebacks)[5 min read

### Prepare chargeback evidence files that a reviewer can actually read](https://evidenz.dev/articles/preparing-dispute-evidence-files)[4 min read

### The customer withdrew the chargeback. Why is the dispute still open?](https://evidenz.dev/articles/withdrawn-chargeback)

Canonical page: https://evidenz.dev/articles/dispute-response-deadlines