Yapture Studio
Sign in

Invoicing

Studio invoices let a provider bill a client organization for project or retainer work, and let that client see and pay what they owe — all without either side leaving the Yapture ecosystem. Settlement runs on Stripe; the Studio API and SDK are the programmatic surface around it.

The two sides

Providers issue

With a provider API key, you create a DRAFT invoice with line items, optionally tie it to a project, set a due date, then send it. Sending finalizes the invoice and emails the client a Stripe-hosted payment page.

Clients view & pay

Signed-in organization members see every invoice for their org, an at-a-glance outstanding / paid / overdue summary, and a one-click pay button that opens the Stripe-hosted page. Card data never touches the portal.

Lifecycle

DRAFT ──update──▶ DRAFT          (edit line items, due date, notes)
DRAFT ──send────▶ SENT           (finalized; client emailed)
SENT  ──paid────▶ PAID           (Stripe webhook → paidAt set)
SENT  ──overdue─▶ OVERDUE        (past dueDate, still unpaid)
OVERDUE ─paid───▶ PAID
DRAFT|SENT ─cancel─▶ CANCELLED
PAID  ──refund──▶ REFUNDED       (admin-initiated)

Only DRAFT invoices can be edited. OVERDUE is derived from dueDate — there is no manual transition into it.

Totals are server-authoritative

When you create or update an invoice you submit only description, quantity, and unitPriceCents per line. The server computes totalCents = quantity × unitPriceCents and the invoice amountCents as their sum, then hands the numbers to Stripe. A client cannot understate what they owe by tampering with totals.

Provider vs client portals

A provider portal (for example, Capswan Studio's internal tooling or the Yapture admin) holds the provider key and performs create/send/cancel. A client portal holds only the member's session token and is strictly read + pay. The same InvoiceClient serves both; the credential decides what is allowed.

Next steps