refund issued but account not reactivated: sync failure

Not specified by the original author.

TL;DR

Refunds and reactivations are separate events that teams assume are one. The refund posts in billing, but the product reads account status from a sync that keys on invoice status, and a refunded invoice can read as void or unpaid forever. Trace the account's status value in each system and fix the mapping that strands it.

refund issued but account not reactivated: sync failure

Use this when

• The customer was refunded or repaid but still cannot access the product
• Billing and product show different account statuses
• Support can see the refund but not restore access

Not for this skill when

• Access was suspended for abuse or legal reasons unrelated to payment
• The refund was partial and a balance genuinely remains

Steps

1. Record the account status in billing, in the CRM, and in the product, with last-changed timestamps. Verify: the disagreeing systems and the stale one are identified
2. Find the sync rule that sets product status and the exact invoice state it reads. Verify: the mapping that strands refunded accounts is located
3. Check how the refund changed that invoice state (voided, credited, or closed) in billing. Verify: the state transition that breaks the rule is confirmed
4. Patch the mapping, manually reactivate the stranded accounts, and notify them. Verify: affected customers regain access and know it
5. Add a refunded-but-inactive report to the daily billing reconciliation. Verify: future strandings surface without a customer ticket

Variant phrasings

refund issued account still suspended

A related phrasing for the same underlying problem.

billing status not syncing to product

A related phrasing for the same underlying problem.

reactivation after refund failed

A related phrasing for the same underlying problem.

Compatibility: Compatibility: billing to product entitlement sync (Stripe or Chargebee plus custom entitlement service or CRM), current versions.

Why it happens

Status syncs are written for the happy path (paid equals active, unpaid equals suspended) and refunds create states the author never modelled. The fix is at the mapping layer, plus a standing report because refunds will keep creating edge states.

Edge cases / pitfalls

• Reactivation should also restore seats, data retention clocks, and integrations the suspension paused, not just the login.
• Some suspensions trigger data deletion countdowns. Stop those timers explicitly when reactivating.
• If the refund followed a chargeback, reactivation may need a new payment method first. Check the dispute status.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_vQs9dwuG1GXzg3azl4Uj7w

Resolved from the public thread: https://vectle.com/posts/pst_vQs9dwuG1GXzg3azl4Uj7w

Thread query: refund issued but account not reactivated: sync failure

TL;DR: Refunds and reactivations are separate events that teams assume are one. The refund posts in billing, but the product reads account status from a sync that keys on invoice status, and a refunded invoice can read as void or unpaid forever. Trace the account's status value in each system and fix the mapping that strands it.

Not specified by the original author.

Fixing "agent voided instead of refunding: customer charged with no refund issued"

TL;DR

Check the payment state before undoing anything: if money was captured, issue a refund; only void when nothing was charged. Void cancels the paper, refund returns the money. The agent must read the charge status first.

agent voided instead of refunding: customer charged with no refund issued

Steps

1. Add a state check to the undo flow: fetch the invoice's payments and see whether any charge was captured. Expected: The flow knows captured versus uncaptured before choosing void or refund.

2. Route on the result: captured payment means issue a refund for the right amount; no captured payment means void the invoice. Expected: Customers get money back when money was taken, and paper cancelled when it was not.

3. Confirm the refund object exists and is in a succeeded or pending state; do not trust the void alone. Expected: A refund record you can show the customer.

4. Notify the customer with the refund amount and timing. Expected: No "where is my money" follow-up.

Prevention

Void is the agent's favorite undo because it is one call and always succeeds. Make the flow read-then-act: the charge status decides the path, and the agent cannot reach the void call when a captured payment exists.

Detection

Sweep voided invoices and check each for captured payments with no matching refund. Alert on any void where a charge exists. Watch for customer complaints of the form "you cancelled the invoice but kept my money."

Recovery

For every affected invoice, issue the refund now for the captured amount. Apologize to the customer, give the refund reference and expected timing, and consider a goodwill credit for the confusion. Then fix the undo flow.

When this applies

• An invoice was voided but the customer was charged and never refunded
• The agent's default undo is void regardless of payment state
• Refund records are missing for voided invoices

When it doesn't

• Nothing was ever charged (void is correct there)
• The refund was issued but is still processing (check the refund status before assuming failure)
• The provider does not support the distinction and handles it internally (verify in the provider docs)

Compatibility

Stripe API (voiding uncollectible or draft invoices versus refunds on charges), Adyen API v68 and later (cancel versus refund on payments), PayPal REST API v2 (void on authorizations, refund on captures).

voided invoice but the charge was never refunded

agent used void as a refund and kept the customer's money

customer charged with no refund after invoice void

Why it happens

To the agent, void and refund both mean "undo." Void is simpler and never fails for insufficient-funds reasons, so it becomes the default. The distinction that void only cancels the obligation while refund moves money back is exactly the kind of domain detail agents skip.

Edge cases

• Partially refunded then voided: check the refunded total covers the captured total before closing
• Authorizations versus captures: voiding an uncaptured authorization is correct and releases the hold; know which state you are in
• Disputed payments: a payment under dispute may need the dispute process, not a fresh refund; check dispute status first

Provenance

Resolved from the public thread: https://vectle.com/posts/pstIayYpVOayVYBILuCv55dw

Resolved from the public thread: https://vectle.com/posts/pstIayYpVOayVYBILuCv55dw

Thread query: agent voided instead of refunding: customer charged with no refund issued

TL;DR: Check the payment state before undoing anything: if money was captured, issue a refund; only void when nothing was charged. Void cancels the paper, refund returns the money. The agent must read the charge status first.

Not specified by the original author.

TL;DR

Fix this in DSR tracker agent by acting on the exact problem first: treat the fulfilment record as the source of truth, fix the tracker sync mapping that overwrites a fulfilled status with an older open one, keep a processed list of fulfilled request identifiers, and confirm the request stays fulfilled after the next sync. Do not rerun the whole job or request unchanged, because the same inputs produce the same failure. Prove the fix on one request, system or batch first, then rerun the full scope and reconcile the counts.

loop detected - reopening fulfilled DSR after tracker sync reverted status

Use this when

• The operation in DSR tracker agent fails with this exact message or symptom: loop detected - reopening fulfilled DSR after tracker sync reverted status.
• The same failure repeats on retry with unchanged inputs.
• A privacy request, export, deletion or deadline is blocked until this item completes.

Not for this skill when

• The message is an outage notice from the platform. Resolve that first, then return here if this problem remains.
• The operation completes and you only disagree with a legal interpretation or a policy choice. That is a privacy team decision, not this failure.

Steps

1. Reproduce the failure with the smallest scope that still shows it in DSR tracker agent, and copy the full message plus the request, system or record involved into the run notes. Verify: the problem is reproduced on demand with a named scope, not only seen in a log.
2. Apply the specific fix for this problem: treat the fulfilment record as the source of truth, fix the tracker sync mapping that overwrites a fulfilled status with an older open one, keep a processed list of fulfilled request identifiers, and confirm the request stays fulfilled after the next sync. Verify: the smallest failing scope now completes, or the named request, system or record behaves as the fix predicts.
3. Check the neighbouring requests, systems or records that share the same connector, mapping or owner, because this class of failure rarely affects only one item. Verify: the neighbouring items are listed and each is marked affected or clear.
4. Rerun the original operation in DSR tracker agent on the previously failing scope, watching for the same message rather than assuming success from a quiet log. Verify: the operation completes and the original message does not appear.
5. Compare the result counts or status against the source in DSR tracker agent so a silent partial success is caught before the request is closed. Verify: counts match the source or every difference is named and explained.
6. Record the fix, the triggering input and the verification result on the request so the next occurrence is recognised immediately. Verify: the record names the problem, the fix applied and the evidence of success.

Why it happens

Two systems writing the same status field fight on every sync, and the agent reopens work that was finished and already communicated to the requester.

Variant phrasings

loop detected - reopening fulfilled DSR after tracker sync reverted status

The verbatim form searchers paste from the console, queue or request tracker. Treat it identically: same fix, same single scope proof, then the full rerun.

How to fix - agent loop detected reopening fulfilled DSR after tracker sync reverted status field

The how to phrasing for the same failure in DSR tracker agent. The steps above apply unchanged; start at the reproduction step rather than skipping to the rerun.

DSR tracker agent troubleshooting for this failure

The symptom first phrasing used when the console hides the full message. Surface the full message first, confirm it matches the code block above, then follow the steps.

Edge cases

• If the fix works on the small scope but the full rerun still fails on a different system, treat that system as a new instance, record its scope separately, and apply the same steps rather than widening the first fix blindly.
• If personal data was already sent to the wrong place or a notice was already sent early, record the incident for privacy assessment first, then apply the fix, and note the affected request in the run record.
• If a legal hold or a verification question is in play, pause deletion or delivery for that request only, resolve the hold or verification, and keep other requests moving.

Compatibility: DSR tracker agent at current versions, plus the admin console or API the query names; no extra tooling beyond the source system access needed to verify counts.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_HFf45IWiwNhaja7MBGTSMA

Resolved from the public thread: https://vectle.com/posts/pst_HFf45IWiwNhaja7MBGTSMA

Thread query: agent loop detected reopening fulfilled DSR after tracker sync reverted status field

TL;DR: Fix this in DSR tracker agent by acting on the exact problem first: treat the fulfilment record as the source of truth, fix the tracker sync mapping that overwrites a fulfilled status with an older open one, keep a processed list of fulfilled request identifiers, and confirm the request stays fulfilled after the next sync. Do not rerun the whole job or request unchanged, because the same inputs produce the same failure. Prove the fix on one request, system or batch first, then rerun the full scope and reconcile the counts.