Invoice System
From the first line item to the payment receipt: an owned invoicing workspace with clear balances, customer PDFs and Stripe and PayPal checkout integrations.
- My role
- Product and workflow design, system architecture, AI-assisted implementation and operational verification.
The problem
A finished job still leaves administrative work: rebuild the scope in an invoice, send a document, find the right payment link and work out what is still owed. When these steps live in separate tools, the same information gets entered again and the next action becomes harder to see.
Constraints
- Keep drafts editable and released documents traceable
- Separate an invoice, a delivery event and a confirmed payment
- Offer payments only where the provider and invoice are configured
Current stage
In operation / scoped payments
One place to follow the invoice
Invoice connects the commercial steps after a job: prepare the bill, review the details, release a numbered document, give the customer access and follow the remaining balance. The staff workspace and customer portal serve different needs, while the invoice remains the common record. This is a standalone application with its own source, configuration and database boundary.
First-hand accountBuild, review and release
Start with the customer, service address and itemized work. Each line has a description, quantity and rate; the editor calculates the subtotal as you work. Review tax, discount, due date and the receipt preference before release. Release produces a numbered invoice and a PDF tied to that version. Delivery is an explicit staff action. The customer portal presents the released items, amount due and available documents.
Know what needs attention
Draft means the invoice is still being prepared. Released invoices show Unpaid, Partially paid or Paid from the outstanding balance. An unpaid remainder past its due date becomes Overdue, including a partially paid invoice. A Released fallback is used when the balance is unavailable. Archive removes an invoice from the active staff view and can be reversed; it does not erase financial history or invalidate customer links. Delivery and receipt-generation states remain separate from payment status.
First-hand accountStripe and PayPal, with evidence
Both integrations are implemented and configured in the reviewed deployment. Stripe uses hosted Checkout; PayPal uses Orders checkout and capture. The portal can resume an open checkout or let the customer change provider after checking the previous attempt. Stripe sandbox payment and signed-webhook settlement were verified, and a scoped live checkout was opened and resumed. PayPal live settlement is recorded. These are different acceptance results: the evidence does not establish a completed live Stripe charge or unrestricted payment availability for every invoice.
Close the loop with a receipt
Verified settlement updates the balance and supports a branded receipt PDF. Operational records confirm a generated receipt and one explicitly authorized receipt email with provider-confirmed delivery. Automatic receipts for future settlements were enabled on October 3, respecting the invoice's delivery preference and excluding historical payments. The first actual payment after that activation was still pending in the reviewed record. A generated PDF, an accepted email and a customer's reading of that email are separate events.
First-hand accountWhy own the workflow
An owned system lets the business shape its invoice fields, document design, release steps and customer experience around the way it works. Its records and integration code can evolve together, and a future connection to field operations can use an explicit API instead of copying data between screens. That connection is an extension opportunity, not a claimed existing integration. Ownership also brings responsibility for hosting, backups, updates and support; Stripe and PayPal remain external services.
First-hand accountThe implementation behind the screens
React and TypeScript power the staff and customer interfaces. Node.js services and PostgreSQL hold invoice versions, payment attempts and settlement records; PDF documents use S3-compatible object storage. Provider callbacks are verified and reconciled against the expected invoice, amount, currency and account. Durable records help avoid repeating a send or capture when a result is uncertain. These are implementation choices supported by source and targeted operational tests, rather than a claim of security certification.
First-hand accountView the technical architecture
Conceptual workflow
- 01Customer and line items
- 02Review and release
- 03Invoice PDF and customer portal
- 04Provider checkout and settlement
- 05Updated balance and receipt
Decisions
- Keep the staff workspace and customer portal separate
- Derive payment labels from the outstanding balance and due date
- Record provider events before reconciling a payment
- Keep archive reversible without rewriting financial history
Evidence
- Invoice editing, PDF release, portal views and balance-based status labels are implementedFirst-hand account
- Stripe sandbox checkout and signed-webhook settlement were verified; scoped live checkout was also opened and resumedFirst-hand account
- PayPal live settlement and a generated receipt are recorded in operational evidenceFirst-hand account
- One authorized receipt email has confirmed provider delivery; future automatic receipt delivery was enabled with its first post-activation payment still pending in the reviewed recordFirst-hand account
Safety boundary
- Screenshots use only fictional local fixtures; they do not show customer records or prove provider delivery
- Payment evidence is dated September 29 to October 3, 2026; provider account status and invoice eligibility can change
- A completed live Stripe settlement is not established by the reviewed evidence
- Owning the application still requires hosting, maintenance and payment-provider services; no fee, savings or compliance claim is made
Working vocabulary
React / TypeScript / Node.js / PostgreSQL / PDF documents / S3-compatible storage / Stripe Checkout / PayPal Orders / Resend
The basis for this case.
Record reviewed: . This describes the published account, not a new check of the project's runtime.
My role, implementation details and unlinked outcomes are first-hand statements. Public sources support only the claims identified alongside them. A project status or screenshot does not independently verify every result.