Merchant payments 2026
Forma
A working merchant payments workspace for Studio / 08, carrying an invoice from creation into a branded customer checkout, a receipt and a reconciled merchant record. A warm blush and espresso identity keeps the financial tools connected to the retailer behind them.
- Merchant workspace
- Invoice management
- Customer checkout
The small moments
of getting paid.
Follow an order from checkout to receipt, then see it in the merchant workspace.
- 01
From invoice to checkout
Build an itemised invoice, select its customer and open a separate customer checkout with the same order total.
- 02
A customer’s own space
The checkout uses the merchant identity and focuses on the order, delivery and payment method, with a dedicated receipt after payment.
- 03
Gross, fee and net
A successful sample payment becomes a paid invoice. Gross collections and available proceeds update with the processing fee accounted for.
A commerce story, from beginning to end
An established dashboard structure, a distinctive identity
A persistent merchant rail, balance and collection summaries, cash-flow chart, recent payment stream and invoice table establish a clear daily working view. Warm surfaces and editorial typography connect it to Studio / 08's customer experience.
Invoice creation with meaningful controls
Choose a saved customer, a catalogue item, quantity, delivery charge and due date. The item subtotal and total update immediately, invalid quantities are rejected, and the new invoice appears in the searchable status-filtered register.
A checkout that carries the merchant's identity
An illustrated product, itemised order and fixed total carry into a dedicated Studio / 08 checkout. Sample card and bank methods lead to a customer receipt with a payment reference, amount, method and invoice number.
Connect the merchant and the customer
The walkthrough follows one invoice across both sides of the transaction. Creating it increases the outstanding total; a local checkout produces a receipt, marks the invoice paid and adds the exact net proceeds to the available balance.
Payment records that reconcile
For the £140 item and £8 delivery, a £148 sample payment deducts a £2.42 processing fee and adds £145.58 to the merchant balance. Invoice status, collection totals, outstanding amounts and payment details all reflect the same local record.
Engineering approach / Proposed architecture
One order. A dependable payment record.
Forma's checkout would connect the merchant's order to a payment provider, then carry that record through confirmation, refunds and settlement. The server would own the amount and payment state; the interface would explain what is happening at each step.
- 01→
Create the order
Calculate the items, delivery and any adjustments on the server. Store a versioned total and create one checkout attempt tied to that order.
- 02→
Collect with the provider
Use provider-hosted fields or wallet components for payment details. Return tokenized references to the application instead of handling raw card data.
- 03→
Confirm the result
Verify and store provider webhook events, then update the payment state. Release fulfilment through a deduplicated job after confirmed success.
- 04✓
Reconcile the sale
Link the order, payment, fees, refunds and payout records. Surface unmatched amounts for review before treating a settlement as reconciled.
Under the surface
The decisions
behind the experience.
Explore the system behaviour, integration choices and operational detail.
A repeated click is the same attempt
Reuse an existing checkout attempt when the same order is submitted again. Pair a database uniqueness rule with a stable provider idempotency key. If the order changes, validate a new version and supersede the previous attempt without creating two active payment paths.
Payment state comes from the server
A browser redirect is not the final payment record. Verify webhook signatures, store event IDs and process events without assuming delivery order. Keep pending, succeeded and failed states distinct; issue the receipt and fulfilment job only once after confirmed success.
Refunds keep their own history
Store each partial or full refund as a linked operation, checking the remaining refundable amount. Track pending, succeeded and failed outcomes independently of the original sale. Reconciliation would account for refunds and provider fees when matching the net payout.
A possible production stack
- Storefront & checkoutNext.js + TypeScript
- Share order, checkout and invoice components while retrieving authoritative totals and payment status from the server.
- Payment collectionStripe Checkout Sessions + Payment Element
- A proposed provider option for embedded, tokenized payment collection. Available methods would follow the merchant's configuration, currency and customer context.
- Order & payment recordsPostgreSQL
- Link orders, attempts, events and refunds with exact amounts and uniqueness rules. Store fulfilment jobs alongside the confirmed state change.
- Processing & reconciliationNode.js workers + provider APIs
- Process stored events, retry unfinished jobs and match provider balance and payout records to the merchant's order history.
Your next fintech product
Make getting paid feel simple.
Tell us about your customers, workflows and technical requirements. We’ll shape the right approach together.
