SaaS Not-as-Described Chargebacks: Prove the Promise, Feature and Remedy

SaaS not-as-described chargebacks are card disputes alleging that purchased software or service differed materially from the offer, description or functionality represented before payment. The useful response compares the customer-specific promise with actual delivery. A login, a paid invoice or a current feature list does not independently answer that comparison.

This guide is for SaaS product, support, billing and payments teams handling claims about missing features, failed onboarding, integrations or outages. Use the subscription chargeback program for lifecycle ownership. For a claim specifically about billing after cancellation, use the cancellation timeline audit.

Classify the complaint before building a software evidence packet

Read the case notice and the customer’s explanation. “The app did not work” can mean the customer never received access, a feature failed, the price changed or the customer did not recognize the merchant. Each allegation can require a different evidence set.

For example, Stripe’s dispute categories distinguish product unacceptable, product not received, canceled subscription and fraudulent claims. Do not reclassify a genuine functionality complaint as fraud merely because the account was used. Follow the processor’s actual category and instructions, including the disputed amount and response deadline.

Write the allegation in one concrete sentence: “The customer says the purchased plan could not export their account’s reports during the disputed monthly period.” That is a more useful investigation target than “unhappy subscriber.” Identify the feature, account, period and represented capability before gathering records.

SaaS not-as-described chargebacks start with the promise at purchase

Preserve the description shown to this buyer: pricing page, checkout, order form, sales email, trial-conversion offer and material support promises. Include plan version, feature limits, compatible systems and relevant availability statements. A marketing experiment or customer-specific order form may differ from the default website.

The promise may be narrow: an available CSV export rather than a custom integration. It may also be broader than the product team remembers: a sales representative could have confirmed support for the customer’s workflow. Keep contradictory material in the investigation rather than choosing whichever version is easiest to defend.

Maintain the relationship between the offer version and the purchase event. A screenshot saved today can illustrate the product, but it should not be labeled proof of the terms shown six months earlier unless that history is established. If the historical version is missing, state the limitation and look for contemporaneous receipts, order forms or communications.

Do not manufacture a reconstructed screenshot and present it as the original customer experience. A labeled reconstruction can help an internal reviewer understand a flow, but the dispute packet must distinguish it from a record captured at the time.

Keep entitlement, availability and use separate

Entitlement describes what the plan allowed. Availability describes whether the capability worked for the affected account and period. Activity describes what the account actually did. None of those records should be silently substituted for another.

For a team product, identify the relevant workspace and user. A colleague’s successful export does not necessarily explain the affected customer’s failed export. For an integration, distinguish a feature your product provides from a third-party credential, unsupported configuration or external outage, using records rather than assumptions.

The seat-based SaaS guide handles quantity and authority questions. The usage-based billing guide reconstructs metered charges. This article instead asks whether the represented service was delivered.

Use a promise-to-delivery worksheet

Build one row per disputed capability or representation. Keep each assertion linked to a dated source, and distinguish a customer report from a confirmed technical finding. A statement such as “customer reports export failed” should remain a report until the investigation establishes more.

The worksheet is an original editorial investigation tool, not a network eligibility test. Its purpose is to prevent an activity export from overwhelming the question the customer actually raised. If there are several issues, identify which ones relate to the disputed payment and address material contradictions.

Worked example: daily logins, failed exports

Imagine a customer pays $300 for a monthly analytics plan that includes exporting their reports. During the disputed period, the customer logs in on 18 days, but a confirmed account-specific defect prevents the required export. Support acknowledges the issue and promises a $60 refund. These are hypothetical facts and amounts.

The 18 login days cannot, by themselves, refute the export complaint. They can show some account activity. The promised $60 refund also needs its own record: approved, initiated, pending, failed or completed. A ticket marked “resolved” does not establish the card movement.

If the customer disputes the full $300, identify what was delivered, what failed and what remedy was actually agreed. The merchant’s internal $60 assessment does not determine the issuer’s outcome or automatically entitle the merchant to recover the remaining $240. Explain the relevant facts and use the permitted response route. The partial chargeback guide covers the separate amount-reconciliation task.

Now consider a different hypothetical case. The accepted plan clearly offers scheduled CSV downloads, the customer confirms that function worked, and the complaint concerns a real-time API available only on a different plan. Preserve the actual purchase-time distinction, successful relevant use and customer communication. Do not rely on an upgraded pricing page or assume that a feature existed because it appears in today’s catalog.

Investigate outages at the customer’s actual scope

A public status page can provide context without establishing every customer’s experience. Match the incident to the customer’s region, workspace, feature and service period. A broad incident may not have affected this account; an account-specific bug may not appear on a public status page at all.

Record the observed impact and how it was verified. Distinguish inability to sign in, partial degradation, delayed results and complete feature failure. Preserve uncertainty when logs are incomplete. Avoid creating a polished uptime figure from a different service, timeframe or denominator.

If the agreement provides service credits, identify the eligibility assessment, approved amount and actual application. A service-level credit can be commercially relevant without being a cash refund or a complete answer to a card dispute. Preserve any separate promise support made to the customer and check the payment-linked remedy history.

Keep onboarding and third-party dependencies explainable

SaaS delivery can depend on configuration, data import or access permissions. Keep the onboarding scope, assigned actions, completion records and customer communications. “Account created” does not establish that a contracted implementation or migration was completed.

If the customer did not complete a required step, show that the step was clearly communicated and relevant to the affected capability. If your team missed an agreed setup action, preserve that finding. The objective is an accurate account of delivery, not a list of reasons to attribute every failure to the user.

For an external integration, identify the supported version and configuration at purchase, the actual connection result and any known limitation. Do not imply a native Chargeflow or third-party connection exists solely because two systems offer APIs. Check current availability and test the actual data path.

Choose an exhibit that tests the disputed feature

Stripe’s sample unacceptable-product packets separate functionality, marketing materials, and support or resolution records. For software, convert that distinction into a feature-specific exhibit index. The reviewer should be able to connect the advertised capability, the affected account and the observed result without treating an unrelated successful action as proof.

Finish each exhibit with one sentence stating the finding and one stating its limitation. For example: “The account’s export failed during the purchased interval; the successful login establishes account access only.” Use the processor’s required submission format and retain the fuller investigation internally.

Build the response around the disputed promise

Use a short narrative with a clear evidence index:

1. Payment and allegation. Identify the amount, service period and specific mismatch alleged.
2. Represented service. Show the relevant offer or accepted customer-specific terms.
3. Delivery evidence. Supply the feature-level records that answer the complaint.
4. Problem and remedy. Include confirmed failures, troubleshooting and actual credits or refunds.
5. Supported conclusion. Explain which facts support the chosen response without promising an outcome.

Generic access logs should remain supporting material when the claim concerns a particular feature. Explain technical codes in ordinary language and include the relevant portion of a record, with its date and source. Do not require a reviewer to sign in to your monitoring system or replay a video to understand the response.

Stripe’s sample evidence guidance separates functionality, marketing material and resolution evidence for unacceptable-product claims. Use the current requirements of the processor handling the actual case. Keep the submission version and confirmation with the internal investigation.

Resolve real defects without duplicating reimbursement

If the service failed or a remedy was promised, assign an owner to the customer outcome as well as the dispute. Before a formal case, use the appropriate support and payment correction process. Once a dispute is open, confirm the permitted financial action and reconcile any existing credit before issuing more money.

A refund does not automatically erase a filed dispute, and an account credit is not a card refund. Record what happened to the payment, invoice and service access separately. Use the double-refund controls guide when support and payments are handling the same customer at the same time.

Improve the product and the evidence process

Track confirmed causes: misleading feature description, wrong entitlement, failed implementation, account-specific defect, broad outage or a mismatch not supported by the checked records. Preserve the customer’s allegation separately from the investigation finding. That separation makes the report useful to product teams without treating a processor label as a diagnosis.

Measure purchase-version coverage, feature-level retrieval time, unresolved evidence gaps, response coverage and posted financial outcomes. For a suspected improvement, compare equivalent plans and service periods rather than interpreting fewer disputes during a low-sales month as proof of success.

Run periodic test cases: an old pricing version, a customer-specific promise, a regional outage and an account with logins but a failed core feature. The test passes when the team can reconstruct the relevant promise and delivery—not when it merely finds an activity file.

Frequently asked questions

Can software be disputed as not as described?

Software can be the subject of a not-as-described or product-unacceptable dispute when a customer alleges it differed from what was represented. The merchant should compare the purchase-time offer with actual delivery for the affected account and period. Follow the case instructions rather than assuming that any login defeats the claim.

Do SaaS usage logs prove that the service was delivered as described?

SaaS usage logs can support specific activity, but they do not independently prove every promised feature worked. A customer might log in while an essential export or integration fails. Match feature-level outcomes to the actual allegation and include known defects, communications and remedies rather than relying on a broad activity count.

What evidence helps with SaaS not-as-described chargebacks?

Useful evidence connects the accepted offer, historical plan and entitlement to the disputed capability’s actual performance. Add relevant incident records, customer communications and the completed remedy history. Preserve source dates and versions, and explain what each record establishes; today’s pricing page is not proof of the offer shown at purchase.

Can an outage support a SaaS chargeback complaint?

An outage can be relevant when it affected the service the customer purchased during the disputed period. Investigate its account, feature and regional scope rather than relying only on a public status page. Any response should address the actual impact, accepted terms and remedy, without treating an internal uptime figure as decisive.

Is a SaaS service credit the same as a refund?

A SaaS service credit is not necessarily a card refund. It might reduce a future invoice or provide additional access without returning money to the original payment method. Record the remedy’s type, amount and completed status, and reconcile it with any chargeback before describing the customer as having been refunded.

Should a SaaS merchant contest every not-as-described dispute?

A SaaS merchant should investigate each complaint and contest only when the facts support a relevant response through the permitted process. Confirmed defects, missing promises and approved remedies need attention even when some service was used. Preserve contradictory records and evaluate the actual payment, claim and evidence rather than pursuing every case automatically.

Connect service evidence to SaaS chargeback recovery

Chargeflow’s merchant documentation describes targeted enrichment as part of its response workflow. Confirm which product, billing and communication records are available in your implementation. Product truth still depends on the source records; automation cannot retrospectively create a missing purchase-time promise.

Use the SaaS software evaluation guide to test how that evidence reaches the right case. Connect your software-delivery evidence to supported recovery workflows with Chargeflow for SaaS.

Source review: October 25, 2026. Worksheets and acceptance tests are original editorial frameworks. Worked cases, identifiers, dates, amounts and internal targets are hypothetical, not customer outcomes or network deadlines. Processor behavior can change; check the current instructions for the actual case.