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 finance needs the correct transaction, invoice state or provider evidence before deciding whether a refund, dispute response or service credit is possible.

Start from the transaction

Follow the path `Billing → Transaction history → Invoice access → Provider state` from `/billing/transactions`.

1. Open /billing while signed in as an account owner or finance reviewer. Result: Billing shows account-scoped subscription, credits and recent transactions.
2. Open Transaction history. Result: the transaction page shows receipts only for accounts you can access.
3. Find the transaction by invoice number, amount, plan, billed date or status. Result: you are working from the provider-confirmed record.
4. Read Invoice access details. Result: you know whether the invoice can be downloaded now or whether provider API access is unavailable.
5. Check provider state before expecting refund or dispute handling. Result: money movement waits for Paddle-confirmed payment and transaction state.
6. Keep the transaction, account and delivery evidence together. Result: any refund, dispute or service-credit decision starts from the same account-scoped record.

Use provider-backed evidence

Refund and dispute decisions need evidence that matches the visible product state.

• Duplicate charge means two provider-confirmed payments exist for the same intended workflow.
• Unsupported before delivery means the product rejected the requested scope before delivering value.
• Quality gate blocked means delivery was blocked by product quality gates.
• Partially undeliverable means the delivered workflow was incomplete but not fully refundable.
• If no refund or dispute action is visible, use the transaction record and provider state as the next evidence source instead of bypassing the account-scoped flow.

Understand credit impact

Service credits and refunds do not automatically rewrite every credit entry.

• Refunded payments and restored credits are tracked separately.
• Consumed credits are not restored by default just because a transaction is reviewed.
• Unsupported targets should stop before consuming credits.
• Provider references may exist in back-office evidence, 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 to a dispute note.

Continue from the outcome

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

• Refunded payments and restored credits are tracked separately.
• Consumed 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).