Show posters by real
humans, with receipts.

Flypost takes a buyer's payment, holds it while a human artist makes a poster, and on approval pays the artist and keeps a fee — then hands over a receipt proving a person made it. Every word in that sentence is a place to get money or trust wrong. Here's how each one is built so it can't be.

Per-order escrow, zero float.

// Stripe Connect, separate charges & transfers

The marketplace holds the buyer's funds until approval, then pays the artist their cut. The naive build routes everything through the platform balance and pays artists out of commingled money — which means the platform is floating cash it doesn't own and reconciliation is a guess.

I built it on separate charges and transfers, and funded each artist payout from its own charge via source_transaction. Every order's money is escrowed against the exact charge that created it: no commingling, no platform float, each order independently reconcilable down to the cent.

The idempotency trap.

Money operations need idempotency keys so a retry can't double-pay. The obvious key — release-{orderId} — is wrong, and subtly so: Stripe replays a key's result, including its failures. A release that failed once (artist not yet verified) became permanently unretryable — the static key replayed the original failure forever.

I replaced it with a per-order Postgres advisory lock (pg_advisory_xact_lock) that serializes releases, plus an adopt-or-create pattern keyed on the charge's transfer_group: any prior money movement is detected and adopted, never duplicated. A failed release now parks the order in a clean approved state, retryable from the operator console.

A race that can't double-spend.

Accept, decline, expire and cancel all touch the same money. An artist accepting a commission at the exact instant a timeout sweeper tries to refund it is a real race — with real dollars on both sides.

Every state transition is a conditional UPDATE with the guard in the WHERE clause, so a transition physically can't fire twice. The refund path re-reads order state under the advisory lock before it creates a Stripe refund. The sweeper can never refund an order the artist just accepted; the accept can never land on one just refunded. Correctness by construction, not by hoping the timing works out.

Provenance you can verify.

Every delivered poster ships with a provenance receipt: a canonical-JSON record (sorted keys, deterministic bytes) signed ed25519 with the platform key. The record embeds its own SPKI public key, so a receipt verifies standalone — no server, no env, no trust in me required. The order page verifies the signature live and demonstrates tamper-detection.

Orders that carry a receipt are undeletable at the database layer (foreign-key RESTRICT) — provenance can't be quietly rewritten. "Made by a human" stops being a marketing line and becomes a signature anyone can check.

One identity, three systems.

A single artist onboarding feeds three things that usually sprawl into three integrations:

• Payouts — Stripe Connect Express, so KYC, bank details and verification are offloaded; the platform requests only the transfers capability and never touches card data.
• Tax — CRA Part XX reporting: the TIN is captured at onboarding, encrypted at the app layer with AES-256-GCM in a versioned v1:iv:ct:tag format built for key rotation, with only the last four digits ever client-visible.
• Provenance — that same verified identity is the signer on the artist's work.

One verified identity, three obligations, captured once and kept consistent.

Correctness over convenience, in the small places too.

• Live preconditions. Release checks capabilities.transfers === "active" against Stripe at release time — the flag that actually governs a transfer — rather than trusting a cached DB flag that lags verification.
• Bounds in SQL. The one-revision limit lives in the query (revisions_used < revisions_included in the WHERE), not in app code where a double-submit could slip the gate.
• Self-healing webhooks. Payment capture has a reconcile-on-page-load fallback — which earned its keep the day a misconfigured webhook secret silently dropped events and payments kept clearing anyway.

Tested against the real Stripe API.

A 48-check smoke suite runs against the live Stripe test API — not mocks. It asserts the money invariants (commission + payout always equals the poster price, to the cent), signs / verifies / tampers provenance receipts, round-trips storage, then drives two complete order lifecycles through the real webhook handler: payment intent → capture → assign → draft → bounded revision → approve → a real Transfer verified for amount and destination → receipt verification → completion. Plus decline-and-refund checked against the Stripe API, and the negative cases. If the payments logic is wrong, the suite fails before anything ships.