Octopoda Pay

Everything that takes payment, in one offer.

In brief

Pay brings together everything that takes payment: the payment terminal, the prepaid account, meal vouchers, the till, and transaction tracking.

It sells in two ways. As an option of Distrib, for the operator who wants their machines to take payment. Or on its own, for the manufacturer who already has their point of sale and wants our terminal driven from their own system.

The trust principle is simple: when the terminal says "paid", it is paid — we only check that the amount and currency are the right ones before serving. The cloud keeps the accounts.

No card number passes through the platform, and the merchant account remains yours.

What it brings : You take payment on your machines without becoming a payment company, or carrying the risk of card data.

In detail

Octopoda Pay brings together everything to do with payment — the terminal applications, the prepaid account topped up online, meal vouchers, the certified bank terminal, the till system, the transaction portal and interface, settlement in several parts. It is sold as the payment option of Octopoda Distrib, or on its own, to whoever already has their point of sale.

The boundary with Distrib. Distrib says what and how much — the priced and validated sale, the catalogue, the offers, the promotions, the field work, the reports. Pay says how it is paid and keeps the record of every transaction.

Two doors

Door	Who	What they buy
The Distrib option	The operator who has Octopoda Distrib: fridges, vending machines, bars, coffee machines.	Payment for their machines and their till: the terminal on the machine, the till system of their staff restaurant, the prepaid account and meal vouchers for their consumers, settlement in several parts, the transaction portal and its actions.
Pay on its own	The manufacturer or integrator who has their own point of sale or machine, and their own back end.	Our terminal, driven by the common vocabulary; the partner interface to close, cancel, refund and retrieve their transactions from their own system; the prepaid account and meal vouchers if they want them.

In both cases, everything is set by configuration: the terminal's role, how it connects, the permitted addresses, the acquirer, the active payment methods. Pay has no per-customer code.

The principle: the certified terminal is what counts, the cloud keeps the accounts

The terminal identifies the customer and carries out the bank payment through the acquirer's certified application, on a terminal locked and managed by the platform: when it says "paid", it is paid — so we serve. Before serving, we only check that the authorised amount and currency are the ones requested.

The cloud keeps the accounts — wallet, vouchers, debts, subsidies — in an append-only ledger, isolated from the rest of the product. No card number ever passes through the platform.

What the suite does

The terminal: one application, two configurations

	What it is	What for
Master	The application is the point of sale: plugged into the machine's socket, it takes payment, approves the selection at the price given by the cloud and reports the sale.	Coffee machine, vending machine: fitting out an existing machine without adding a box.
Slave	The same application, configured to serve a point of sale that is elsewhere: the embedded box of a fridge or a bar over the local bus, or a networked machine controller.	Fridge, bar, machine controller, kiosk: the machine keeps its selling logic.

In both cases, the terminal is a device of the fleet: identity, converged configuration, monitoring, technician screen, updates from the platform.

One vocabulary to drive a terminal

A point of sale requests — pre-authorise, capture, cancel, refund, read a badge, show a screen — and the terminal publishes its state and the result of each order.
The same vocabulary for every point of sale, whatever the connection.
Three journeys carried by that vocabulary: identification (badge, visual code), the bank payment delegated to the certified application, and the dynamic screens.
Each order replays without double effect, and an unknown order is refused by name.
The terminal writes its log before acting, not after.
A sale whose outcome is unknown is reported as such, never guessed.
A pre-authorisation is closed by whoever must close it: the point of sale, or a server.
Failing that, it is cancelled on timeout, with an alert.

The prepaid account and online top-up

Wallet: balance, history, top-up at preset amounts, and automatic top-up with its threshold, amount and monthly ceiling.
Online top-up: the card is registered once through a verification with no charge, and later top-ups happen without re-entering it — with cancellation and refund possible.
Vouchers named or bearer, credit notes, employer subsidies, and debts recovered automatically at the next top-up.

Digital meal vouchers

A means of payment like any other: an eligible base per product, a share bounded by the daily legal ceiling, the rest settled by the prepaid account, the subsidy or the card. In a demonstration, a simulated provider plays the same contract and each voucher is marked "simulation".

The certified bank terminal

The certified module handles charging, refunds, reservation, cancellation, contactless, code reading and batch settlement. The Android terminal adds partial capture at the amount actually due. The merchant account at the acquirer is the customer's own.

The partner interface and notifications

Close, cancel, refund server to server, without the card.
Retrieve its transactions page by page, each with its history.
Export them over a given period.
A key sees only its own customer, is shown once, and can be revoked.
An idempotency key is mandatory on every call that moves money.
Every operation is recorded append-only.
Incoming notifications from providers, whose authenticity is verified by reading back at the acquirer before any effect; and signed outgoing notifications to the customer's system.

One sale, several parts — and disputes

Settlement in several parts: terminal, prepaid, voucher, subsidy, meal voucher.
In priority order, with the remainder becoming a debt.
A replay resumes, it never charges twice.
What is not settled is not charged: a doubtful sale goes through review first.
An authorisation for a different amount than requested is cancelled, never served.
Disputes: raised from the receipt, credit notes, refunds. A same-day refund is a full cancellation.

The transaction portal and its actions

View each transaction: machine, terminal, till or online payment.
Means, nature, provider, amount requested and amount settled.
Indicators per means, filters and export.
Refund in full or in part, capped at the refundable amount.
With a reason taken from a closed list, never free text.
Issue a credit note, cancel, close a pre-authorisation at the amount due.
The same actions through the interface, for a partner's system.
A single refund ceiling, shared by the portal and the interface.
Every action is idempotent and recorded append-only.

The till system

Configurable till screens operated by a seller: several baskets, split settlement, customer identification in three modes, re-pricing before settlement. The catalogue and the offers come from Distrib.
Till session: a cash float at opening, a count at closing, a logged discrepancy, a numbered and immutable closing report by means, rate and seller, with chained receipts.
The same accounts, badges and subsidies as the machines; every settlement joins the transaction portal.

The trust foundation

The terminal's "paid" is what counts, with amount and currency checked before serving.
An append-only ledger, in an isolated module: the card surface and the providers' secrets do not leave it, and the rest of the product never reads its schema.
The publisher's secret only goes to the designated application, verified by its fingerprint.
Encrypted link only between the terminal and the platform.
A real terminal never switches to simulated payment.
A single production key signs the application, kept in the vault: publication refuses a debug build, a different key or multiple signers.

Where it shows

Surface	Audience	What is shown
Transaction portal	The operator, the manager	Each transaction and its parts, the indicators, the filters, the export; refund, credit, cancel, close.
Terminal screen	The customer	The payment status band and the dynamic screens.
Technician screen	The installer	Listening address and port, bound point of sale, effective settings with secrets masked, logs — opened by code.
Till site	The seller	Till screens, session, cash count, closing report.
Consumer site	The consumer	Payment methods, registered card, top-up, wallet, receipts, disputes.
Partner interface	The manufacturer's system	Transactions, history, export, closing, cancellation, refund.
Console	The fleet operator	The terminal as a device of the fleet: state, version, configuration.

What it receives from the others

From Distrib, when Pay is its option: the catalogue, the offers and the prices.
Plus the validated sale, the consumers, the organisations and the reports.
From Fleet: management of the terminal as a device — identity, heartbeat, converged configuration, monitoring, managed secrets, immediate cut-off, application catalogue. Pay uses it, it does not rebuild it.
From the Octopoda foundation: the isolated account, the portal, the alerts, the white labelling.