Refunds, disputes and service credits

Before requesting money movement

Refunds, disputes and service credits all start from a stored transaction in the account that owns the payment. Do not start from public pricing, email screenshots or raw provider IDs. Use this page when a visible billing row offers a refund reason, service-credit reason or dispute evidence package and you need to choose the next automated action.

Start from the transaction

Follow the path `Billing → Transactions and evidence → Refund or service-credit action → Dispute evidence JSON` from `/billing/transactions`.

1. Open /billing while signed in as an account owner or finance reviewer. Result: Billing shows account-scoped subscription, credits, transactions and refund/service-credit state.
2. In Transactions and evidence, find the transaction by invoice number, amount, plan or status. Result: you are working from the provider-confirmed record that can support a refund, service credit or dispute package.
3. Read the Refunds and service credits summary before clicking any action. Result: you know whether prior requests, refunded credits or transferred credits already exist.
4. Use Duplicate charge only when the same payment was collected twice for the same intended workflow. Result: WebRiskOps records a refund request and, when provider access is available, submits the Paddle refund action.
5. Use Unsupported before delivery, Quality gate blocked or Partially undeliverable only when the visible workflow state matches that reason. Result: the request follows the automated refund or service-credit policy instead of a manual support exception.
6. Use Dispute evidence JSON when a provider dispute or chargeback needs evidence. Result: the evidence file contains account, transaction, plan and delivery evidence without exposing customer secrets in the UI.

Request a refund or service credit

Refund and service-credit buttons are policy choices. Use the reason that matches the visible product state.

• Duplicate charge is a provider refund path for repeated payment collection.
• Unsupported before delivery is a refund path when the product rejects the requested scope before delivering value.
• Quality gate blocked is a service-credit path when delivery was blocked by product quality gates.
• Partially undeliverable is a service-credit path when the delivered workflow was incomplete but not fully refundable.
• If the action is missing, read the disabled reason or unavailable reason first; do not create a side-channel support request that bypasses the account-scoped record.

Download dispute evidence

Dispute packages collect account, transaction, plan and delivery evidence needed to answer provider chargebacks.

• Use Dispute evidence JSON only on the matching completed or billed transaction.
• The evidence file can include invoice number, account context, plan key, workflow state, delivery evidence and chargeback evidence log summaries.
• Provider references may exist in the downloaded package for provider handling, but customer-facing Billing pages should keep raw provider IDs hidden.
• Do not add card details, payment method secrets, provider credentials or private customer data outside the generated evidence package.

Continue from the outcome

Service credits are a separate resolution path. They do not automatically reverse consumed workflow credits.

• Refunded credits and transferred credits are tracked separately.
• Consumed scan or fix credits are not restored by default.
• A duplicate charge can have a different resolution than a completed scan the customer no longer wants.
• Unsupported scope before delivery should stop the workflow and show the available refund/service-credit path.
• If provider access is unavailable, use [Provider connection errors](/docs/troubleshooting/provider-connection-errors) and wait for the product to restore provider access before expecting provider-side refund submission.
• If the issue is subscription access or renewal timing, continue to [Cancellations and renewal](/docs/billing/cancellations-and-renewal).