Octopoda Pay

Tout ce qui encaisse, en une offre.

L'essentiel

Pay réunit tout ce qui encaisse : le terminal de paiement, le compte prépayé, les titres-restaurant, la caisse, et le suivi des transactions.

Il se vend de deux façons. En option de Distrib, pour l'exploitant qui veut que ses machines encaissent. Ou seul, pour le fabricant qui a déjà son point de vente et veut notre terminal piloté depuis son propre système.

Le principe de confiance est simple : quand le terminal dit « payé », c'est payé — on vérifie seulement que le montant et la devise sont les bons avant de servir. Le cloud, lui, tient les comptes.

Aucun numéro de carte ne transite par la plateforme, et le compte marchand reste le vôtre.

Ce que ça apporte : Vous encaissez sur vos machines sans devenir un acteur du paiement, ni porter le risque des données de carte.

En détail

Octopoda Pay regroupe tout ce qui est lié au paiement — les applications du terminal, le compte prépayé rechargé en ligne, les titres-restaurant, le terminal bancaire certifié, le système de caisse, le portail et l'interface des transactions, le règlement en plusieurs parts. Il se vend comme l'option qui encaisse d'Octopoda Distrib, ou seul, à qui a déjà son point de vente.

La frontière avec Distrib. Distrib dit quoi et combien — la vente tarifée et validée, le catalogue, les offres, les promotions, le terrain, les rapports. Pay dit comment c'est payé et garde la trace de chaque transaction.

Deux portes

PorteQuiCe qu'il achète
L'option de DistribL'exploitant qui a Octopoda Distrib : frigos, distributeurs, bars, machines à café.L'encaissement de ses machines et de sa caisse : le terminal sur la machine, le système de caisse de son restaurant d'entreprise, le compte prépayé et les titres-restaurant pour ses consommateurs, le règlement en plusieurs parts, le portail des transactions et ses gestes.
Pay seulLe fabricant ou l'intégrateur qui a son point de vente ou son automate, et son propre système.Notre terminal, piloté par le vocabulaire commun ; l'interface partenaire pour clore, annuler, rembourser et retrouver ses transactions depuis son système ; le compte prépayé et les titres-restaurant s'il les veut.

Dans les deux cas, tout se règle par configuration : le rôle du terminal, son raccordement, les adresses admises, l'acquéreur, les moyens de paiement actifs. Pay n'a pas de code par client.

Le principe : le terminal certifié fait foi, le cloud tient les comptes

Le terminal identifie le client et réalise le paiement bancaire par l'application certifiée de l'acquéreur, sur un terminal verrouillé et géré par la plateforme : quand il dit « payé », c'est payé — on sert. Avant de servir, on vérifie seulement que le montant et la devise autorisés sont bien ceux demandés.

Le cloud tient les comptes — porte-monnaie, bons, dettes, subventions — dans un journal en écriture seule, cloisonné du reste du produit. Aucun numéro de carte ne transite par la plateforme.

Ce que fait la suite

Le terminal : une application, deux configurations

Ce que c'estPour quoi
MaîtreL'application est le point de vente : branchée sur la prise de la machine, elle encaisse, approuve la sélection au prix donné par le cloud et remonte la vente.Machine à café, distributeur : l'équipement d'une machine existante sans ajouter de boîtier.
EsclaveLa même application, configurée pour servir un point de vente qui est ailleurs : le boîtier embarqué d'un frigo ou d'un bar par le bus local, ou un automate en réseau.Frigo, bar, automate, borne : la machine garde sa logique de vente.

Dans les deux cas, le terminal est un appareil de la flotte : identité, configuration convergée, supervision, écran technicien, mise à jour depuis la plateforme.

Un seul vocabulaire pour piloter un terminal

  • Un point de vente demande — pré-autoriser, capturer, annuler, rembourser, lire un badge, afficher un écran — et le terminal publie son état et le résultat de chaque ordre.
  • Le même vocabulaire pour tous les points de vente, quel que soit le raccordement.
  • Trois parcours portés par ce vocabulaire : l'identification (badge, code visuel), le paiement bancaire délégué à l'application certifiée, et les écrans dynamiques.
  • Chaque ordre se rejoue sans double effet, et un ordre inconnu est refusé par son nom.
  • Le terminal écrit son journal avant d'agir, pas après.
  • Une vente dont l'issue est inconnue est dite comme telle, jamais devinée.
  • Pré-autorisation clôturée par qui doit la clôturer : le point de vente sur le terminal, ou un serveur. À défaut, elle est annulée automatiquement au délai, avec une alerte.

Le compte prépayé et la recharge en ligne

  • Porte-monnaie : solde, historique, recharge à montants prédéfinis, et recharge automatique avec son seuil, son montant et son plafond mensuel.
  • Recharge en ligne : la carte est enregistrée une fois par une vérification sans débit, et les recharges suivantes se font sans ressaisie — avec annulation et remboursement possibles.
  • Bons nominatifs ou au porteur, avoirs, subventions employeur, et dettes recouvrées automatiquement à la recharge suivante.

Les titres-restaurant dématérialisés

Un moyen de paiement comme les autres : une assiette éligible par produit, une part bornée par le plafond légal journalier, le reste étant réglé par le prépayé, la subvention ou la carte. En démonstration, un fournisseur simulé joue le même contrat et chaque titre porte la mention « simulation ».

Le terminal bancaire certifié

Le module certifié assure le débit, le remboursement, la réservation, l'annulation, le sans-contact, la lecture de code et la télécollecte. Le terminal Android y ajoute la capture partielle au montant réellement dû. Le compte marchand chez l'acquéreur est celui du client.

L'interface partenaire et les notifications

  • Clôturer, annuler, rembourser de serveur à serveur, sans la carte.
  • Retrouver ses transactions page par page, chacune avec son historique.
  • Les exporter sur une période donnée.
  • Une clé ne voit que son client, ne se montre qu'une fois, et se révoque.
  • Clé d'idempotence obligatoire sur tout appel qui bouge de l'argent.
  • Chaque opération est tracée en écriture seule.
  • Notifications entrantes des prestataires, dont l'authenticité est vérifiée par relecture chez l'acquéreur avant tout effet ; et notifications sortantes signées vers le système du client.

Une vente, plusieurs parts — et les litiges

  • Règlement en plusieurs parts : terminal, prépayé, bon, subvention, titre.
  • Par ordre de priorité, le résiduel devenant une dette.
  • Un rejeu reprend, il ne re-débite jamais.
  • Ce qui n'est pas réglé n'est pas débité : une vente douteuse passe d'abord en revue.
  • Une autorisation pour un autre montant que celui demandé est annulée, jamais servie.
  • Litiges : contestation depuis le ticket, avoirs, remboursement. Un remboursement le jour même est une annulation totale.

Le portail des transactions et ses gestes

  • Consulter chaque transaction : machine, terminal, caisse ou paiement en ligne.
  • Moyen, nature, prestataire, montant demandé et montant réglé.
  • Indicateurs par moyen, filtres et export.
  • Rembourser en tout ou en partie, plafonné au remboursable.
  • Avec un motif pris dans une liste fermée, jamais en texte libre.
  • Émettre un avoir, annuler, clôturer une pré-autorisation au montant dû.
  • Les mêmes gestes par l'interface, pour le système d'un partenaire.
  • Un seul plafond de remboursement, partagé par le portail et l'interface.
  • Chaque geste est idempotent et tracé en écriture seule.

Le système de caisse

  • Écrans de caisse configurables tenus par un vendeur : plusieurs paniers, encaissement fractionné, identification du client en trois modes, re-tarification avant encaissement. Le catalogue et les offres viennent de Distrib.
  • Session de caisse : fond de caisse à l'ouverture, comptage à la fermeture, écart journalisé, rapport de clôture numéroté et immuable par moyen, taux et vendeur, avec des tickets chaînés.
  • Les mêmes comptes, badges et subventions que les machines ; chaque encaissement rejoint le portail des transactions.

Le socle de confiance

  • Le « payé » du terminal fait foi, montant et devise vérifiés avant de servir.
  • Journal en écriture seule, dans un module cloisonné.
  • Le reste du produit ne lit jamais ses données : secrets et surface carte n'en sortent pas.
  • Le secret de l'éditeur ne part qu'à l'application désignée, vérifiée par son empreinte.
  • Liaison chiffrée uniquement entre le terminal et la plateforme.
  • Un terminal réel ne passe jamais en paiement simulé.
  • Une seule clé de production signe l'application, gardée au coffre-fort : la publication refuse une application de débogage, une autre clé ou plusieurs signataires.

Où il se voit

SurfacePublicCe qu'on y voit
Portail des transactionsL'exploitant, le gestionnaireChaque transaction et ses parts, les indicateurs, les filtres, l'export ; rembourser, créditer, annuler, clôturer.
Écran du terminalLe clientLe bandeau d'état du paiement et les écrans dynamiques.
Écran technicienL'installateurAdresse et port d'écoute, point de vente lié, réglages effectifs avec les secrets masqués, journaux — ouvert par code.
Site de caisseLe vendeurÉcrans de caisse, session, comptage, rapport de clôture.
Site consommateurLe consommateurMoyens de paiement, carte enregistrée, recharge, porte-monnaie, reçus, contestation.
Interface partenaireLe système du fabricantTransactions, historique, export, clôture, annulation, remboursement.
ConsoleL'opérateur du parcLe terminal comme appareil de la flotte : état, version, configuration.

Ce qu'il reçoit des autres

  • De Distrib, quand Pay en est l'option : le catalogue, les offres et les prix.
  • Plus la vente validée, les consommateurs, les organisations et les rapports.
  • De Fleet : la gestion du terminal comme appareil — identité, signal de vie, configuration convergée, supervision, secrets gérés, coupure immédiate, catalogue d'applications. Pay l'utilise, il ne la refait pas.
  • Du socle Octopoda : le compte cloisonné, le portail, les alertes, la marque blanche.

Cette documentation est produite à partir de la base produit Arkipelis. Elle décrit les capacités de la plateforme.