Trial-to-paid disputes: reconstruct the agreement and the first charge
Discuss with AI
Opens an AI with a question about the public article URL. Check its answer and sources.
The page must be published. Access and prefilled text are not guaranteed; copy the prompt if needed. Only the public URL and this prompt are passed along.
A trial conversion needs more explanation than a successful payment. Reconstruct the price and billing interval shown at signup, the trial end, any reminders or cancellation attempts, and the service available after conversion. Usage during a free trial does not by itself establish agreement to a later paid period.
In this article
A trial-to-paid dispute concerns the transition from an introductory offer to a billed subscription. The customer might deny agreeing to recurring payment, say they canceled during the trial, or report that the promised service was unavailable. Identify that specific claim before collecting evidence. A successful charge answers none of those questions on its own.
Reconstruct the offer the customer actually saw
Find the signup flow and terms version used for this account. Record the trial duration, introductory price if any, post-trial amount, currency, billing interval, and cancellation route. Use historical records rather than a screenshot of the current pricing page.
Keep the offer text separate from the acceptance event. A pricing page establishes what was displayed; a linked checkout or account event helps establish which offer the customer accepted. A generic terms timestamp with no recorded version leaves an important question open.
Stripe’s current trial documentation covers free, paid, and other introductory offers with configuration-dependent behavior. Inspect the actual subscription rather than assuming every trial follows the same free-period-to-monthly-plan pattern. An account’s trial end and first invoice may also differ from an example used in a marketing page.
If the business cannot retrieve the relevant offer, say so in the internal review. Do not replace the missing version with today’s more explicit wording and present it as historical evidence.
Polar lets a trial configured on a Checkout Link or Checkout Session override the product’s trial settings. For a Polar order, inspect the relevant checkout and subscription dates. The product’s current default may not explain the duration offered to this customer.
Trace the reminder through the sending system
Stripe’s trial-compliance guide distinguishes Stripe-hosted reminders from messages sent by the business and describes the settings involved. Check which mechanism was configured for this customer. A feature being available in the dashboard is not proof it was enabled when the trial began.
For your own messages, connect the trial-ending event to the email job and delivery result. Record the destination, template version, send time, and any bounce or failure. Do not turn receipt of a webhook into a claim that the customer received or read an email.
The provider’s exceptions matter too. Polar’s trial reminders can be disabled, and it skips them for subscriptions already scheduled to cancel at period end. Check the settings and state relevant to this trial rather than assuming every automatic conversion produced a reminder.
Review the message content as well as its status. Did it clearly identify the product, impending amount and billing interval, and a usable cancellation route? This is a practical review of the record, not a claim that one message satisfies every network rule or consumer-law requirement. Consult the requirements applicable to your provider, offer, and market separately.
Put cancellation attempts before the conversion decision
Search support messages and account actions for requests made during the trial. Distinguish a request timestamp from the time an operator processed it and the effective cancellation date. If a request was timely but the business handled it late, a later billing-system timestamp should not conceal that sequence.
Check whether a cancellation link worked for the customer’s account state. A route that required a login the customer could not complete may help explain an unresolved complaint. Preserve relevant access errors and support replies instead of presenting the absence of a completed cancellation event as the whole story.
The canceled-subscription guide goes deeper on effective dates. Here, the important boundary is whether the first paid conversion followed the offer and the customer’s recorded actions.
Separate trial activity from paid-period activity
Build a short sequence: offer accepted, trial started, reminder handled, cancellation requested if any, trial ended, first payment attempted, and paid access granted. Keep failed payment attempts distinct from completed charges.
Product activity should identify the account, event, and time. Downloads during the introductory period can show use of the trial. They do not by themselves demonstrate acceptance of a later price. Likewise, a paid account may retain access after a refund discussion without proving that the complaint was resolved.
Illustrative example. A trial starts on October 1 and converts on October 15. The activity log contains exports on October 3 and 8, while a support message requests cancellation on October 13. A response saying “the customer used the paid service” would misstate the date range. The useful review examines the October 13 request and whether any activity actually occurred after conversion.
Make the response follow the finding
If the offer was unclear, the reminder failed, or cancellation was mishandled, document that finding and choose an appropriate resolution through the provider. Do not assemble unrelated activity to obscure a billing error.
If the records support challenging the dispute, connect each relevant fact to its source and answer the actual reason shown on the case. Stripe publishes different evidence guidance for different dispute categories. The chargeback-evidence guide explains how to make those links readable.
Finish with a separate prevention task: improve an unclear offer, repair a broken cancellation path, or monitor failed reminder jobs. Describe the defect the case revealed rather than assuming every trial dispute has the same cause.
Keep the trial and the first paid period in one review
Evidenz is being built for B2C SaaS subscriptions and B2B workspace trials, where billing, support, account, and product records each hold part of the explanation. For an individual subscriber, trace the offer accepted by that account; for a company trial, also establish which workspace and approving person it concerned. The useful history connects that offer, reminder result, cancellation request, first paid invoice, and activity in the relevant period. Reviewing the sequence together should make mismatches visible, such as a timely cancellation followed by a charge. A busy trial account cannot establish agreement to conversion. Missing terms or delivery records should remain visible as gaps.
Sources and scope
Sources checked
Published by Evidenz. Examples are illustrative, not customer results. Check current requirements and the actual case against the linked sources.