What does the `refund` transaction type in Credits History mean?

A refund row in your Valid Email Checker Credits History records credits returning to your account. Refunds always show positive credits_in and zero credits_out. They flow into the same bucket the original deduction came from — Monthly refunds back to Monthly, PAYG refunds back to PAYG, rollover refunds back to rollover.

The most common cause: Unknown auto-refund

Our verification engine occasionally returns an Unknown result. Unknown means we could not confidently say whether the address is valid, even after running the full check chain (MX lookup, SMTP probe, etc.). Charging you for a result you cannot rely on would be unfair, so any Unknown result automatically refunds the credit it cost. A row is logged with transaction type "refund", credits_in = 1 (for a single-email refund) or the matching count for a bulk job, and the description typically references the email or task that triggered the refund.

Less common: manual goodwill or correction refunds

Support sometimes issues a refund manually — for example, if a bulk job ran during an outage on our side, or if you reported a billing anomaly. Manually issued refunds use the same refund transaction type and look identical to auto-refunds in the table, but the description usually mentions the reason ("Goodwill refund for service interruption", etc.).

Refunds preserve the original bucket

If a credit was originally taken from your Monthly bucket and later refunded, the refund row is tagged "monthly" and the credit returns to Monthly. The same for PAYG and the legacy rollover bucket. This is important because the buckets have different expiration rules (see Monthly vs PAYG) — refunding to PAYG when the credit came from Monthly would effectively convert reset-credits into never-expire-credits, which is not what we want.

A bulk job with Unknown results produces multiple rows

A 1,000-email bulk job that produced 50 Unknown results does not get one bulk_verification row offset by one refund row. Instead, the original deduction shows the full 1,000 credits drained, and a separate refund row appears with credits_in = 50 once the Unknown auto-refund processes (usually within the same minute). Looking at both rows together gives you the net cost: 1,000 deducted, 50 refunded, 950 effective.