The front desk takes a card on the processor's own page, and the receipt goes back into the practice management system by itself. Everything below is what makes that one sentence true.
| Piece | What it is | What it does |
|---|---|---|
| Front desk app | Local web app on the practice's own PC, Node 22, no cloud hop for patient data | Find the family, show the plan, hand off to the card page, show the receipt |
| Family's page | Same app, opened on a phone by link or text | Authorize, sign, pay, receipt |
| Practice bridge | .NET 8 client speaking the practice system's own service layer | Reads the ledger and the due list; writes the receipt and closes the instalment |
| Card page | The processor's hosted page | Takes the card. Our software never sees or stores a card number |
| Admin and licence | Subscription state per practice | Switches a practice on or off. Scheduled payments keep running during grace |
| Step | What happens | Where |
|---|---|---|
| 1. Find | Two letters of a surname finds the family and the plan, read live from the practice system | Practice system |
| 2. Confirm | The plan, the amount due and the technology fee are shown as one total | Front desk |
| 3. Authorize | The family ticks one consent and signs. Marketing consent is asked separately, after the money | Family's phone |
| 4. Card | A session is opened with the processor and the card is entered on the processor's page | Processor |
| 5. Approval | The approval is read back by its own reference before anything is recorded | Processor |
| 6. Write back | The receipt is posted to the family's ledger and the instalment is closed | Practice system |
| 7. Proof | The open payments count moves by exactly one, on the practice's own screen | Practice system |
| Item | Who pays | Where it lands |
|---|---|---|
| The instalment | The family | The practice's own ledger, in full |
| Technology fee | The family, on every payment | Us. One authorization on the card, one line on the statement |
| Processing | Confirmed by the processor for the practice | Not our line |
| Control | What it refuses |
|---|---|
| No card data | The card is entered on the processor's page. We hold no cardholder data |
| Subject fence | Any write to a record that is not the one we were given permission for. Unreadable is treated as a real patient, never as permission |
| Write permit | Every write needs a permit re-armed from a confirmed read, inside a two hour window |
| One chokepoint | All three write paths pass through a single guard. Nothing writes around it |
| Exactly once | Each charge is keyed to database, plan, instalment and due date. A replay is refused, a genuine new one is not |
| Rate ceilings | Counted against an append only ledger, not a timer in memory |
| Attended | A person at the practice fires every write. Nothing writes into the practice system on its own |
| Record | What is in it |
|---|---|
| Call ledger | Every call to the processor, append only, with the spacing between them |
| Sign in ledger | Every sign in to the practice system, written before the attempt, not after |
| Ledger reads | A stamped copy of the plan as the practice system gave it, with a hash |
| Close intent | The exact receipt we asked the practice system to post, kept next to what it answered |
| Machine lines | One structured line per card, per write and per permit, so any run can be graded later |
| Alarm log | Anything the software wanted to warn about, kept internally rather than shown to a patient |
| Area | Detail |
|---|---|
| Desk runtime | Node 22 web app, served on the practice's own machine on a local port. No inbound port is opened to the internet |
| Practice integration | .NET 8 client speaking the practice system's own service layer. Two components: one that only reads, one that writes, so the reading path cannot write by accident |
| Reads | The family's ledger, the list of instalments due, the office's posting accounts and tender types, and the open payments count |
| Writes | Post the receipt against the plan, then set the instalment closed. Two calls, in that order, never one without the other |
| Card handling | A session is opened with the processor, the card is entered on the processor's page, and a token comes back. No card number reaches our software or our logs |
| Approval check | The approved amount is read back from the processor by its own reference and that figure, not the requested one, is what gets recorded |
| Exactly once | Every charge carries a key built from the database, the plan, the instalment and its due date. The same key twice is refused; a genuinely new instalment is not |
| Where data sits | Patient data stays on the practice machine. What leaves it is the payment request to the processor and nothing else |
| Failure behaviour | If a write cannot complete, the charge is not silently kept: the intent is written to disk with what the practice system answered, so a person can see exactly what happened |
| Ledgers | Append only files for processor calls, sign ins, plan reads and write intents. Counters are read from those files, not from memory, so a restart cannot reset a limit |