# Customers can download a receipt

Fictional example: Northstar customer portal. Names, work and results are illustrative.

## Outcome
A signed-in customer can download a PDF receipt for their own completed order from the order page.

## Why this matters
- Who needs the result: customers who need a record of payment.
- Current problem: they ask Support to prepare a receipt.
- Useful change: they can retrieve the same agreed payment information themselves.

## Scope
- Included: one receipt download action on completed orders, using the approved receipt fields.
- Outside this request: refund receipts, bulk downloads and email delivery.

## Context and sources
- Current facts: the order page already identifies the signed-in customer and the order payment state.
- Sources: the agreed receipt-format document and the order-page design, linked in the real work item.
- Access check: the contributor and reviewer must open both current sources before starting. The example supplies no private links.

## Constraints and open questions
- Constraints: use the existing access check and PDF approach; add no new dependency without approval.
- Open questions: confirm the displayed payment-date timezone before implementing the PDF.
- Dependencies: the reviewer must confirm the receipt fields and timezone first.

## Deliverables
A reviewed code change, tests for download and access behavior, and a short verification note linked from the work item.

## Acceptance checks
- [ ] A completed order shows a PDF download action; the PDF has the correct order number, payment date and paid amount.
- [ ] A customer cannot download another customer's receipt; incomplete orders offer no receipt.
- [ ] A failed download shows a clear message and lets the customer try again.
- [ ] The reviewer can find the output and verification evidence.

## Review and handoff
- Contributor: a developer or connected agent chosen by the team.
- Reviewer: the portal product owner checks the receipt fields; a second developer checks access and failure behavior.
- Required approval or external action: review the change before deployment; deployment is a separate authorized step.
- Handoff: link the code, test results and any unresolved check. Keep the work in review while a required check remains.