Digital service not received: choose evidence that shows delivery

Define what delivery meant for this purchase

A SaaS subscription may promise a paid feature, a generated report, a company workspace, or a quantity of API calls. Start with the purchased plan and the description shown at that time. Then ask what records would demonstrate that particular promise was fulfilled.

Provisioning an account might be enough to explain one step of delivery. It does not establish that a paid export worked. Likewise, consuming credits does not show that a customer received usable output if the operation failed after the credits were deducted.

Stripe’s product-not-received guidance includes digital access and usage records linked to the customer. The useful connection is between the claim, the purchase, and the relevant event. The task is not to accumulate the largest possible number of logs.

Follow the path from purchase to usable result

Reconstruct the steps the service required. A typical review might follow payment, account provisioning, permission assignment, attempted use, completed work, and access to the result. Your service may have fewer or different steps.

Use your actual event definitions. If “report viewed” fires when a browser opens an empty page, describe that behavior rather than presenting it as proof that a report was read. Ask the team responsible for the event when the instrumentation is unclear.

Match the activity to the payment and service period

Use stable account and billing identifiers to connect records. Check workspace membership and plan scope, especially where one person can switch among accounts. A successful download in the free workspace does not establish delivery of a paid team feature.

Keep the billed period visible. An account may have worked last month but failed immediately after renewal. Previous successful use provides history; it does not settle whether the disputed month was delivered.

Also record who or what initiated the action. Separate customer sessions from support impersonation, internal monitoring, imports, scheduled integrations, and retries. Otherwise a business can mistake its own troubleshooting for customer use.

Use these checks as an investigation method. The applicable evidence requirements still come from your payment provider and the dispute category.

A completed job can still leave the customer without a result

Fictional example. A customer pays €80 for a SaaS subscription that includes exporting a research report. The worker log says the report job completed at 14:02 UTC. The next event is a download request at 14:04 that returned an access-denied response. Support reproduces the permissions problem at 14:20.

A packet containing only the completed-job record would omit the delivery failure. The customer’s claim is consistent with the failed download even though the backend performed the computation.

The internal finding should name both facts: the service generated a report, but the customer could not retrieve it through the purchased workflow. Investigate whether the problem was corrected, when usable access became available, and what the business promised during support. Those facts inform the decision; the word “completed” does not decide it.

If the records instead show a successful download of the correct report followed by a message discussing its contents, that supports a different account of delivery. Still check that the records concern the disputed purchase, and preserve any complaint about an unusable or incomplete result.

When access worked but a promised capability was missing, investigate whether the SaaS service matched its description. Evidence of opening the account does not answer a complaint about the function supplied.

Address the actual reason, not every possible reason

Service delivery and payment authorization are separate questions. A report download can be relevant to “I did not receive the service.” It does not automatically answer “I did not authorize this payment” or “I canceled before the renewal.”

Stripe distinguishes dispute categories and their evidence requirements. Read the actual case and any customer explanation before selecting the packet. If the complaint concerns quality rather than non-receipt, do not quietly reframe it as an access question because the access logs look favorable.

Shopify lists access or usage records among evidence merchants can add for digital goods and services. Include the record in a form the external reviewer can understand, with a short explanation of its connection to the purchase.

Turn technical events into a readable response

Write a short service description and a dated sequence. Explain the meaning of each selected event and include the relevant record itself. Avoid unannotated JSON, internal dashboard links, and unsupported statements about the customer’s intent.

Stripe recommends concise, relevant evidence and readable attachments. A useful final check is to have someone outside the engineering team read the packet. They should be able to identify the promised service, the delivered result, and any unresolved limitation without knowing your event names.

Retain the broader investigation separately. It may explain an outage, broken entitlement, or reporting problem the business should fix even after the dispute ends. The customer timeline guide describes how to preserve sources and uncertainty; the evidence guide covers selecting the final packet.

For B2B and B2C SaaS teams, Evidenz is designed to make the purchased service the centre of the investigation. Its customer-timeline approach connects the payment and account relationship with the entitlement change, access attempt, usable result, and support conversation relevant to that purchase. Support and finance need an explanation they can review without treating every technical event as delivery. In the report example, that means carrying the failed download alongside the completed job. The resulting decision can acknowledge a genuine access failure or explain verified delivery from the records that actually concern the disputed service.