Routing
A route, not a rewrite
A route in your configuration decides where a payment goes. Adding a second processor is another adapter and another route.
Payments
DineStack makes nothing on your card payments
You connect your own payment account. The rate you pay is between you and your processor, and DineStack takes no share of it — not a percentage, not a per-transaction fee, not a markup hidden in a hardware price.
- $149 a month, and that is the whole bill
- Your own account, your own bank
- Card data never touches our servers
Architecture
Processor-neutral by construction
DineStack talks to a processor through one adapter boundary. Stripe is what V1 ships with — Connect for the account, Terminal for the readers — but nothing above that boundary knows the word Stripe.
Scope
Card data never enters our infrastructure
The reader talks to the gateway and hands back a token. That is what keeps the compliance surface small — and what makes the paragraph above possible.
Tenders
Every way money actually arrives
Four of them, and one has been through a physical certification run.
Certified
Cash
Counted, change worked out, drawer reconciled at close-out with the variance named rather than absorbed. Proven on the tablet with the network pulled.
Pending
Card reader
A Bluetooth reader paired to the tablet, or tap to pay on the tablet itself where the hardware supports it. Chip and PIN for Interac in Canada.
Pending
Backup terminal
When the card route is down, take the payment on an independent terminal and record it: the exact amount, a human confirming it was approved, marked as externally confirmed rather than as a processor result.
Pending
Split and multi-tender
Any number of shares, any mix of methods, in any order. Money is divided by allocation rather than division, so the shares always add back to the bill.
Where each of those stands. Cash is certified on the tablet — an order tendered, the change worked out, the drawer reconciled, with the network pulled. The other three are not there yet. Card payments run through Stripe Terminal. The server side is live-verified; the reader itself has not yet been certified on our hardware. Recording a payment taken on an independent terminal is built and tested; no physical backup terminal has been run end to end yet. Split checks and multi-tender are proven in the money core and in the system certification; neither has yet been exercised on a tablet in a physical run.
An externally confirmed payment is labelled as one. It is somebody’s word that a terminal approved a charge, and until the terminal’s own batch confirms it, reconciliation counts it separately. DineStack does not report a claim as a verified fact just because it is probably true.
Reconciliation
Reconciliation that names the order
This is the part incumbents do not build, because building it would expose their own fee errors.
- 1 — CounterOrder
- 2 — KitchenTicket
- 3 — TenderPayment
- 4 — ProcessorSettlement
- 5 — BankDeposit
- Order-level granularity
- The whole way along, on a tamper-evident hash chain — not a daily total that has to be believed.
- Unresolved exposure is a number you can see
- Payments whose outcome never came back are counted as in doubt. Not as revenue, and not as nothing.
- Refunds trace to the tender they came out of
- A refund on a split bill knows which share paid.
- Disputes open themselves
- A verified chargeback callback opens a dispute with the deadline on it, rather than being deduplicated and dropped.
- Processor health is measured, not assumed
- When the till says the card route is degraded, that is an observation.