Hand a dispute from support to finance without losing the customer’s history

Transfer a case, not a ticket link

“Finance is handling it” can leave two teams waiting for each other. Support may believe the customer's complaint is resolved. Finance may see an open dispute and no explanation of the resolution. A ticket link helps only if the receiver knows which payment, commitment, and next action it concerns.

The handoff record below is a suggested operating practice. Adapt roles and approvals to your organization. It does not assume a particular tool or that a support agent should have permission to submit dispute responses.

Start by naming one case owner and one next action. The owner can delegate the research, but someone needs to verify the deadline and the eventual provider action. Keep the customer's communication separate from the status of the formal case.

Identify the payment relationship too. Polar’s buyer terms describe Polar as merchant of record and authorized reseller, and say it may submit evidence to the issuer to contest a chargeback. For a Polar purchase, the handoff should distinguish your business’s record owner from the party handling the payment dispute. Confirm the actual response route instead of assuming finance can submit through your own processor account.

For reseller-sold orders, the Merchant of Record guide separates seller identity, case control, evidence channels, and supplier-balance effects. Put that response route in the handoff before assigning a submission task.

Include the fields that change the decision

Check the payment-to-account connection before transferring a long history. If a person belongs to two workspaces, note which workspace the charge covers. If the match is uncertain, put that uncertainty near the case identifier rather than burying it in a comment thread.

Preserve what support actually promised

Illustrative case. A €95 monthly media subscription loses access for several days. Support restores access and promises a two-week service extension. The customer later disputes the charge, saying the promised credit was never received. Finance receives a short handoff: “Credit agreed; customer refunded.”

That sentence changes two facts. The promise concerned service time, and there is no verified refund. Finance cannot determine the appropriate next step from the summary alone.

A better handoff links the original promise, the restoration record, and any extension event. It records whether the extension was applied and preserves the customer's explanation. It also leaves room to investigate whether the proposed resolution was appropriate; a support message alone does not settle every obligation.

Do not quietly edit the old summary and lose its history. Add a correction, identify the source, and notify the current owner that the previous description was inaccurate. If a response draft used it, that draft needs review too.

Make the deadline visible to both teams

Use the deadline and case actions shown by the payment provider. Record a stated time zone and an internal review point early enough to leave room for approval. Your internal review point is a team control, not a different bank deadline.

If the owner is unavailable, name a backup and an escalation route. When a handoff arrives close to the deadline, say which facts remain unresolved. Do not mark a case complete because the question was forwarded or because the customer has stopped replying.

Include the last provider-status check time. A handoff prepared yesterday can be accurate about customer history and stale about today's available actions. Recheck the live case before submitting a response or initiating a money movement.

Keep the original and the submitted version

Source links support investigation, but they may require permissions or show later edits. Preserve the relevant original records through your authorized retention process, with identifiers and timestamps. Keep unrelated conversations and credentials out of a broadly shared case note.

Stripe recommends relevant, readable evidence rather than relying on an external reviewer to reconstruct the case. Before submission, produce a smaller set that explains this charge and claim. Keep the investigated history distinct from the exact packet filed.

When the provider action completes, retain its confirmation, time, actor, and submitted version. If it fails, record the failure and keep ownership open. “The button was clicked” is not the same state as “the provider accepted the response.”

WorkOS’s Audit Logs event API accepts an organization ID and an event containing an action, actor, targets, and occurrence time. That structure can record an internal approval or correction with the relevant case reference. Keep it separate from the provider’s action confirmation: recording “approved for submission” in your application does not establish that the payment provider received the packet.

Close the communication loop

Tell support what was decided and which customer message is appropriate. Tell finance when the customer supplies new facts. Keep acceptance, submission, pending review, and final outcome as distinct states.

Review recurring handoff failures: missing payment identifiers, altered promises, unowned cases, stale statuses, and absent confirmations. Fixing those fields is often more useful than adding another summary paragraph. The timeline guide covers the record model; the response guide covers the action from investigation through confirmation.

Give the next reviewer the same case history

Evidenz is designed around the gap between a SaaS payment case and the customer history held in support and product systems. In B2C, a handoff needs to preserve the promise made about an individual's subscription. In B2B, it also needs to identify the company workspace, billing contact, and scope of the commitment. Evidenz's development focus is a shared timeline that connects those records without losing their sources. The next reviewer should be able to trace the exact promise, access problem, and money movements. Named ownership, approvals, and current provider confirmation remain essential parts of the operating process.