# Receipts & viewing keys

> Disclose individual payments when proof is needed, from a single receipt to a full receive-history audit.

The tools in this group disclose payment history to a third party, like an accountant or auditor. Each disclosure reveals exactly what you choose and can be verified independently against the chain.

## The disclosure ladder

The tools form a ladder from narrow to broad, and the right choice is the narrowest rung that satisfies the request.

-   A **payment receipt** proves one outgoing payment. The sender packages the payment's [note](../concepts/notes) material into a JSON file, and anyone holding it can recompute the note's [commitment](../concepts/commitments-and-nullifiers) and confirm it exists on-chain, with no keys changing hands.
-   A **shared secret** proves one incoming payment. The recipient derives a per-note decryption secret from their [viewing key](../concepts/keys) and that single note's on-chain event, so an auditor can read exactly that note while every other one stays sealed.
-   The **viewing key** itself opens your full receive history, past and future, for as long as you keep using the wallet. It still cannot spend, but there is no un-sharing it, so it is the option of last resort.

Verification runs client-side against public chain data. The person you hand a disclosure to needs no account, none of your keys, and no cooperation from you beyond the disclosure itself, and a forged or altered receipt fails its checks.

## In this group

-   [Generate a payment receipt](../operations/generate-receipt): package proof of one outgoing payment.
-   [Verify a payment receipt](../operations/verify-receipt): the four checks an auditor runs.
-   [Share a single-note secret](../operations/share-single-note-secret): disclose one incoming payment.
-   [Disclose your viewing key](../operations/disclose-viewing-key): the full receive-history option and its consequences.