Unrecognized subscription charges: a recognition workflow for support

A customer who does not recognize a subscription charge may be seeing an unfamiliar merchant name, an unexpected renewal, a second account, or an unauthorized payment. Start by identifying the charge. Calling the report “friendly fraud” before that investigation turns an unanswered question into an accusation.

Match the statement entry to a specific payment

Ask for the displayed merchant name, amount, currency, approximate date, and whether the entry is pending or posted. Follow your support verification process before discussing account details. A full card number or security code is not a useful support shortcut.

Find the payment in the processor, then the corresponding invoice and subscription. Record which provider account contains it. If several payments fit, do not choose the first match and assume the investigation is complete.

Confirm what the customer is asking. “I have never heard of this company” differs from “I know the product but canceled last month.” The latter needs the cancellation chronology, even if the initial support category was an unrecognized charge.

Explain the name on the statement

Stripe’s statement-descriptor documentation describes the merchant text that explains a payment and notes that some banks may display it incorrectly or omit it. Compare the descriptor recorded for the payment with what the customer reports. Do not assume today’s account setting is the text used on a historical charge.

A useful explanation connects the names: the statement entry, the product name the customer would recognize, and the billed service. Avoid sending a corporate registration name alone when the customer signed up for a differently named application.

Check who sold the order as well as which application supplied the service. Polar acts as a merchant of record and reseller of digital goods and services. For a purchase made through Polar, trace the order there. Its customer portal provides purchase history, invoices, and payment receipts, which can help connect the payment to the product. Verify the actual statement text; the reseller relationship alone does not establish which descriptor the bank displayed.

Illustrative example. A customer knows an application as “Note Harbor” but sees a different operator name on their statement. Support locates a €24 renewal, matches it to the relevant monthly invoice, and explains the relationship between the two names. That can answer the recognition question. It does not independently establish that the cardholder agreed to the renewal.

Reconstruct what the payment covered

Use the original invoice and account records to describe the product, plan, service period, amount, and currency. Find the receipt or renewal message and distinguish a created message from a delivered one. A record that a notification was generated is not proof that someone read it.

Check trial conversion, billing frequency, plan changes, and multiple workspaces. A customer expecting a monthly subscription may be asking about an annual invoice. A team member may have purchased an add-on. These are hypotheses to test against records, not explanations to present as facts before checking.

Keep the investigation tied to the disputed purchase. Activity from another account or a later billing period does not explain this charge merely because the name or email looks familiar.

An account match is not cardholder authorization

Stripe’s Customer object has a unique record identifier and separate contact fields. Treat those as distinct pieces of information. A billing email can route a receipt; it does not establish who physically used a card or whether an employee was authorized to make the purchase.

Use verified links between the payment, subscription, application account, and relevant user. The identity-resolution guide describes how to retain those links and their uncertainty. If an account appears compromised, route the case through the appropriate security process instead of treating subsequent account activity as proof against the cardholder.

When the customer still denies authorization, do not pressure them to withdraw a complaint simply because you found an invoice. Explain the facts you can verify and preserve the unresolved issue.

If a dispute is already open, answer its recorded reason

Stripe’s categories documentation treats unrecognized payments alongside authorization concerns and supplies reason-specific evidence guidance. The exact category and requirements depend on the live case. Use those instructions rather than building a response around a support tag.

Retain the customer’s actual words, the matching payment records, and any later acknowledgment. “I recognize the product now” and “I authorized this purchase” are different statements. A reviewer should not silently turn one into the other.

Finish the support response with a concrete account of the payment and an appropriate next step: explain a verified renewal, correct a billing error, investigate access or authorization, or coordinate the open dispute. Review descriptor and receipt clarity afterward. The immediate goal is a reliable answer for this customer; prevention work should follow what the case actually revealed.

Give support a recognizable account of the charge

Support should be able to explain which product, account, and billed period sit behind an unfamiliar statement entry. Evidenz is designed for this work in B2B and B2C SaaS: a customer timeline linking the payment relationship with account changes, subscription history, and relevant conversations. The benefit is continuity when a recognition question becomes a cancellation, delivery, or authorization investigation: the next reviewer starts from the same identified purchase and the customer’s actual words. That gives the team a concrete explanation to discuss while keeping recognition and payment authorization as separate conclusions.