Section 11 · Pricing, Proposals & Closing
11.8Deposit / payment capture
Built in the POC- No.
- 11.8
- DMA's reference
- Decision Book p.26
- Phase
- Phase 1
- Autonomy
- L2 · Prepare, then wait for approval
- DMA's decision
- Yes
◆ Amended in v3 of the book.
What DMA asked for · Decision Book p.26
Move a closed deal from a signed agreement to a collected deposit, without anyone invoicing or chasing by hand.
Why it matters to DMA: Otherwise "the AI closes" still waits on manual billing.
In our words, from DMA's Product Decision Book v3, page 26.
How we do it
- Once the contract is signed, the deposit invoice waits for a person's approval (L2 to start). Then a hosted checkout is created for the deposit from the approved proposal, with a retry-safe key.
- The payment is reported back by the provider and checked against the expected amount. When it's paid, Closed/Won is staged for Nutshell through the write gate.
- In the POC the provider is a payment simulator; a real processor is a configuration change. Refunds and declines are recorded in plain words, and one kill switch pauses every provider call.
The flow
It plays on its own while it's on screen; hover or use the controls to pause or step through.
Signed
The contract is back.
- Stored data
- Person
- Screen
- Rule in code
- Nutshell
Where the data goes
The same six stages on every page. Nothing reaches Nutshell except through the write gate.
- 1Approved proposal
Source
The deposit amount.
- 2Sync
Copies Nutshell changes into the bridge database
Mirrors Won back from Nutshell.
- 3Bridge database
A copy of the CRM data, plus what the AI works out
The transaction and its events.
- 4AI
Claude models, only through DMA's own gateway
Not involved: the closing path is code.
- 5Write gate
The only way back into Nutshell: checked, approved when needed, sent once
Writes Closed/Won once paid.
- 6Nutshell
The system of record
The deal is Won.
The tables behind it
Drawn from the POC's database catalogue: structure only, no data.
PK primary keyFK reference the database enforces (solid line)ID reference kept by id (dashed line)
| Table | What it holds | Columns |
|---|---|---|
| ctrl.transactions | The closing path: amounts, checkout and payment. | 30 |
| ctrl.outbox | The Closed/Won change, written once. | 28 |
How the tables connect (3)
| Column | Points to | Kept by |
|---|---|---|
| ctrl.transactions.signature_approval_id | ctrl.approvals | The database (foreign key) |
| ctrl.transactions.invoice_approval_id | ctrl.approvals | The database (foreign key) |
| ctrl.outbox.approval_id | ctrl.approvals | The database (foreign key) |
Worked example
Synthetic demo data: every name, business and number is made up.
The payment steps, in the dashboard's words (sample).
Payment steps
| Step | Shown as |
|---|---|
| 1 | Signed; the deposit invoice waits for a person's approval |
| 2 | Deposit invoice sent |
| 3 | Deposit paid |
| 4 | Won: deposit paid and the deal marked Won in Nutshell |
In the running POC
1 / 2Sample: an approved proposal, the step before signature and payment.sample data
- 1The proposal and its version.
- 2The price lines, priced by code from the rate card.
- 3Send proposal, available only once it is approved.
Dashboard · a proposal ready to send (sample). Captured from the running POC on September 25, 2026; synthetic data.
See it live
Opens the exact screen in the running POC, in a new tab.
| Open | Where | What to try |
|---|---|---|
| Approvals | DMA AI dashboard | Payment-link approvals appear here. |
Status
Built in the POC. This capability runs in the POC today, on synthetic data, end to end.