Les échanges nécessaires pour commander, payer et réserver. Pour chacun : les données transmises par Memoria et la réponse attendue de Looply.
Des besoins fonctionnels, pas onze endpoints imposés.
Paiements, commandes, réservations ; événement de remise du code en option.
Existant, à développer, reporté ou impossible — avec coût et délai.
Boissons : interface Memoria, catalogue, commande, caisse et paiement Looply.
Réservation : réservation des jeux et animations et paiement dans votre widget, depuis l’application Memoria ; présentation des activités et suivi dans Memoria. L’entrée par votre portail complet est une variante acceptable si l’entrée directe par activité n’est pas disponible.
Le client peut commander sans compte Memoria et sans choisir de table. Retrait au bar par défaut ; livraison en cabine privée sur demande avant paiement.
Memoria gère ses comptes, le carnet invité, les points, les équipes temporaires, les classements et son CMS multisite. Les données transactionnelles de Looply alimentent ces fonctions. Les outils de caisse et l’app barman restent fournis par Looply.
Le suivi repose sur vos statuts réels, sans bipeur ni estimation de durée obligatoire.
Le catalogue, l’arrivée en caisse et le paiement ont été décrits oralement comme disponibles. Le partage d’addition a également été évoqué comme existant, à revalider. Cela ne vaut pas encore confirmation de leur accès par une application tierce.
Si une capacité nécessaire au parcours manque, merci de proposer la solution disponible et son incidence sur le coût et le délai. Les écrans et le périmètre seront reconfirmés ensemble avant développement. Une réponse « reporté » ou « impossible » ne vaut pas validation d’un retrait de fonctionnalité.
A01–A11 décrivent des capacités attendues, pas onze endpoints à créer. A08 désigne l’ouverture du widget ; A10 peut rester dans ce widget. Les événements et les lectures peuvent se compléter ou se remplacer selon les mécanismes disponibles.
| Parcours | Réponse immédiate | Confirmation et suivi |
|---|---|---|
| Identité · A01 | Une référence personne utilisable dans les échanges, ou confirmation du mécanisme de référence externe. | Cette référence accompagne les commandes, parts, paiements et réservations. Aucun webhook de compte supplémentaire demandé. |
| Commande et paiement · A03–A06 | Panier accepté, référence de commande, parts éventuelles et session de paiement. | E01 confirme l’encaissement ; A07 permet de relire le même état. Le retour navigateur seul ne valide aucun paiement. |
| Préparation et remise · A04/A07 | La commande est reçue avec son mode de service et sa cabine éventuelle. | E02 ou A07 fournit le statut réel. La règle de démarrage de préparation, notamment en paiement partagé, reste à confirmer. |
| Réservation · A08/A09 | Le widget s’ouvre avec un contexte conservé ; aucune réservation acquise à cette seule étape. | E03 ou A09 confirme la réservation et son paiement. E01, s’il existe aussi, est rapproché de cette même opération. |
| Annulation · A10 | La demande est prise en compte, en attente ou refusée. | E03 ou A09 donne l’issue réelle ; un remboursement éventuel reste suivi avec sa référence et son état propres. |
| Reprise après incident · A11 | Les opérations modifiées ou les références à relire sont retrouvées. | A07/A09 ou un rejeu d’événements rétablit l’état courant. Pas de nouvel encaissement déclenché par la reprise. |
Pour chaque opération, merci de préciser : existant / adaptation à développer / reporté / impossible, puis la documentation ou un exemple, les limites, le délai et le coût éventuel.
Référence externe opaque de la personne/session, lieu ; référence client Looply si déjà connue
Référence client ou mécanisme de corrélation réutilisable dans les commandes, paiements, réservations et événements. Préciser si un client Looply doit être créé ou si une référence externe suffit. A01 peut être couvert par un paramètre des opérations existantes, sans appel dédié.
Référence établissement ; éventuellement catégorie
Identifiants produits et options, catégories, libellés, descriptions, images, composition et allergènes des boissons lorsqu’ils sont fournis ; prix et devise, choix obligatoires ou facultatifs et suppléments, disponibilité et horaires de commande. Préciser les quantités maximales ou stocks exposés et le traitement des informations absentes.
Lieu, articles, quantités, options, code promotionnel éventuel
Articles/options et quantités acceptés, ruptures ou changements de prix, réduction réellement applicable, total à payer et détail des montants. Peut être couvert par la création de commande si elle permet de présenter les corrections avant paiement. Préciser la durée de validité du montant et la nouvelle validation requise si le panier change avant encaissement.
Référence externe de commande, personne/session, lieu, lignes validées, mode retrait/livraison, cabine si livraison, clé évitant une création en double
Identifiant et numéro de commande, référence externe reçue, montant confirmé, statut initial, service retenu et référence utilisable pour paiement/suivi. Préciser à quel moment elle devient visible et préparée en caisse. En cas de réponse perdue, indiquer comment retrouver la même commande par la clé initiale, sans en créer une seconde.
Commande, nombre de parts ou montants selon votre mécanisme, référence de chaque payeur ; pourboire individuel distinct, dont la prise en charge est à confirmer
Identifiants stables des parts, référence de chaque payeur, montants hors pourboire, états payé/en attente/échoué et solde. La somme des parts couvre le total de la commande sans écart de centimes ; les pourboires individuels s’ajoutent séparément. Préciser les règles si une part reste impayée, les modifications encore permises et comment retrouver les mêmes parts après une réponse perdue. Une part déjà payée ne peut être recalculée ni encaissée à nouveau.
Commande ou part, payeur corrélé, montant attendu et pourboire individuel distinct, URL de retour ; référence de tentative pour éviter les doublons. Ces données couvrent aussi le paiement individuel sans partage
Lien ou session de paiement hébergé, référence de paiement liée à la commande ou à la part, montant confirmé hors pourboire, pourboire et total à régler, expiration, moyens disponibles et règle de nouvelle tentative. Une session créée ne vaut pas encaissement. Préciser la protection contre deux règlements simultanés de la même part et le devenir d’un ancien lien lors d’une nouvelle tentative. Les données carte restent dans votre solution de paiement.
Identifiant commande ; ou filtre autorisé par personne et lieu pour l’historique
Numéro, lignes, total, parts avec leurs payeurs, références et états des paiements, montants encaissés et pourboires distincts, état de préparation, retrait/livraison et cabine, dates de mise à jour ; estimation uniquement si disponible. Fournir les règles et états d’annulation/remboursement, sans les confondre avec un échec de paiement.
Lieu, référence opaque de tentative reliée à la personne, URL de retour ; activité/date si présélection possible
URL ou configuration d’intégration mobile, paramètres autorisés, mécanisme conservant la corrélation jusqu’à la confirmation. Ce n’est pas une demande d’API native de création de réservation.
Référence réservation, ou référence de tentative transmise au widget ; références corrélées de la personne et du lieu pour son historique
Activité, date/créneau, participants si utile, référence de réservation, personne corrélée, référence et état du paiement, état de réservation, montant, instructions d’accès et possibilité d’annuler. Avant confirmation d’une annulation, fournir les conditions applicables, le délai limite et les frais ou le remboursement prévu lorsqu’ils sont déterminables ; ces informations peuvent rester présentées dans le widget si l’annulation s’y déroule. Préciser le mode de délivrance du code d’accès et, lorsqu’il est accessible, comment le relire après sa remise au desk pour le conserver dans Memoria. Aucun code non encore délivré ne doit être affiché.
Référence réservation et personne autorisée ; protection contre les demandes répétées
Demande acceptée, en attente, exécutée ou refusée avec motif ; état réel de la réservation et traitement du remboursement s’il s’applique. Une annulation ne prouve pas qu’un remboursement est terminé. Peut être réalisé dans votre widget si Memoria peut ensuite relire le résultat fiable.
Lieu, période ou curseur de dernière synchronisation
Commandes, paiements et réservations créés ou modifiés, y compris annulations/remboursements, avec les mêmes références stables, dates de mise à jour et pagination. Préciser la période conservée et la règle de reprise. Un rejeu d’événements, des lectures par références connues ou un export exploitable peuvent couvrir ce besoin. La solution doit aussi retrouver une réservation dont Memoria n’a pas reçu l’identifiant : une simple lecture par identifiant déjà connu ne couvre pas ce cas. Préciser le délai de reprise et les éventuelles interventions manuelles.
Identité (A01). L’authentification Memoria reste distincte : aucun SSO ni gestion de ses mots de passe chez Looply n’est demandé. La récupération du carnet invité après connexion est réalisée par Memoria. Il faut pouvoir conserver l’accès aux références Looply des opérations antérieures et rattacher les événements tardifs à la bonne personne. Si votre modèle exige une association ou fusion de clients chez vous, merci de préciser l’opération nécessaire ; aucune fusion de comptes n’est présumée.
Lieu et cabine (A02/A04). Une correspondance configurée entre les lieux Memoria et vos établissements peut suffire : pas d’appel de résolution du QR à chaque arrivée. Même principe pour les quatre cabines. Si vous imposez vos identifiants de zones, fournissez la liste ou l’appel de lecture. La mention « livraison en cabine X » doit parvenir à la caisse et à l’opérateur ; une information conservée seulement dans Memoria ne suffit pas.
Paiement partagé (A05). La maquette propose des parts égales et un pourboire propre à chaque payeur. Merci de confirmer le fonctionnement réellement disponible, les paiements simultanés et le déclenchement de la préparation. L’attente du règlement de toutes les parts est une règle de démonstration à qualifier, pas un comportement Looply établi. L’équipe temporaire reste gérée par Memoria : elle ne doit pas devenir une table ou un compte partagé obligatoire chez vous.
Historique (A07/A09). Une lecture sécurisée par références connues de Memoria peut remplacer une liste par client, si elle permet de retrouver tous les changements. Les participations payées doivent être retrouvables même si une autre personne a créé la commande. Pas besoin de deux mécanismes redondants.
Activités (A08/A09). Les fiches éditoriales sont gérées dans le CMS Memoria avec une référence vers votre activité. Un catalogue d’activités accessible par API peut être utilisé s’il existe ; sa création n’est pas demandée. Les créneaux, tarifs et disponibilités restent dans votre widget.
Retour du widget (A08/A09/E03). La référence de tentative doit être restituée ou résoluble par un mécanisme serveur, même si le navigateur est fermé avant la redirection ou si le retour est perdu. Préciser comment distinguer attente, échec certain et réservation confirmée avant de relancer le widget. L’absence de retour ne doit jamais être assimilée à un échec définitif. Indiquer aussi les confirmations e-mail ou SMS déjà envoyées par Looply afin d’éviter les doublons ; aucune personnalisation supplémentaire de ces messages n’est imposée ici.
Jeux et animations (A08/A09/E03). Tous les parcours se font dans l’application Memoria. Les réservations de jeux et d’animations, avec le choix du créneau, des participants et le paiement, passent par le widget Looply. Memoria doit retrouver la réservation, son paiement et la personne concernée via E03 ou A09 ; les points sont attribués à partir de cette confirmation vérifiable, sans double crédit si E01 décrit le même paiement.
Visites et tampons. La règle de validation des visites reste à convenir avec les porteurs du projet. Si elle s’appuie sur une transaction ou une activité vérifiée, Memoria utilisera les retours retenus ci-dessous. Aucun événement de visite ni développement de fidélité supplémentaire n’est exigé de Looply par défaut ; E04 reste facultatif.
Une redirection du navigateur sert à retrouver l’écran Memoria. Elle ne suffit pas à prouver qu’un paiement ou une réservation est confirmé : il faut un événement vérifiable ou une relecture serveur.
Référence du paiement et de la commande ou réservation concernée ; part si applicable, payeur corrélé, montant réellement encaissé, devise, pourboire et remise distincts, état et date. Pour un remboursement, si applicable : référence du paiement d’origine, référence unique du remboursement ou cumul remboursé vérifiable, montant et état du remboursement, part ou payeur concerné. Distinguer remboursement partiel, total et en attente pour éviter une double correction des points
Mettre à jour l’addition et attribuer les points au bon payeur, une seule fois ; corriger selon les règles retenues lors d’un remboursement.
Commande, lieu, état, date, service et cabine ; estimation facultative
Actualiser le suivi client. Merci de donner votre liste réelle de statuts et les actions opérateur qui les déclenchent. « En livraison » ne sera utilisé que si cet état existe.
Référence et état de la réservation, lieu, contexte de corrélation, personne ou payeur identifiable par cette référence, activité, créneau, référence et état du paiement, montant et date
Retrouver la réservation et actualiser le carnet. Distinguer réservation créée, confirmée et payée. Si E01 et E03 décrivent le même encaissement, leurs références doivent permettre à Memoria de ne créditer les points qu’une fois.
Réservation, type d’action et date ; code délivré ou moyen de le relire si cette information est exposée
Affiner le suivi et les actions disponibles. À qualifier séparément, sans en faire un prérequis nouveau au lancement.
Pour les événements : identifiant unique, référence de l’objet et du lieu, date/version, moyen de vérifier l’origine, règles de livraison et de nouvelle tentative. Les doublons ou événements reçus dans le désordre ne doivent pas créer de double paiement ni de double attribution de points. Memoria gère la déduplication de ses traitements.
Si les webhooks ne sont pas disponibles, merci d’indiquer les lectures autorisées, leur fréquence et leurs limites. Une lecture périodique peut couvrir le suivi si elle permet une actualisation acceptable et un rattrapage fiable.
Contrats d’échange : Pour les échanges retenus, fournir un exemple de réponse réussie et d’erreur : champs obligatoires ou absents, références de rapprochement, états possibles, devise et unité des montants, distinction entre montant de commande, pourboire, remise et remboursement, format des dates et fuseau. Préciser aussi le traitement d’une clé déjà utilisée, d’une réponse perdue et d’une opération encore en attente. Un événement peut ne contenir que des références si une relecture autorisée fournit ensuite les détails nécessaires.
Widget : confirmer le mode d’ouverture depuis Memoria sur mobile, notamment la faisabilité d’une iframe, les origines autorisées, les contraintes de session/cookies et le retour après paiement. L’entrée directe par activité, la suppression du menu/pied de page et les couleurs sont à qualifier et chiffrer séparément de l’intégration nécessaire. Le portail complet et le style fournisseur restent des variantes prévues.
Données personnelles : si Looply conserve des coordonnées ou consentements pour cette intégration, préciser les lectures/modifications accessibles et la procédure de suppression ou d’anonymisation. Aucune synchronisation marketing ni outil de campagne n’est demandé. Signaler les données que vous devez conserver et le traitement possible lorsqu’un client demande la suppression de son compte.
Multisite : indiquer comment les accès sont limités à chaque établissement et comment la même personne peut être reconnue dans plusieurs lieux. La création de lieux et les droits du CMS restent gérés par Memoria ; seule leur correspondance avec vos établissements et accès est attendue de Looply.
Accès techniques : documentation et exemples, environnement et paiements de test, identifiants de test, authentification serveur et droits par établissement, limitations de débit, versionnement, interlocuteur technique et procédure d’incident ; préciser la disponibilité du support en soirée et le week-end ainsi que les modalités d’annonce des maintenances.
Les points, tampons, équipes, classements, QR et règles de validation des visites sont gérés dans Memoria ; aucun développement de ces fonctions n’est demandé à Looply. Les récompenses par palier, les notifications push et les bipeurs sont hors du périmètre proposé. Aucun moteur de calcul d’attente ni accès général au planning n’est demandé si les statuts, le widget et la lecture des réservations couvrent les parcours.
La référence est la maquette de parcours actualisée. Chaque lien ci-dessous ouvre l’écran avec ses données d’exemple ; les liens à l’intérieur de l’application conservent ensuite la session. Les écrans finaux restent à concevoir à partir de la charte. Les données sont simulées et ne prouvent pas la disponibilité des API Looply.
Aperçu V2 et scénarios · Application en plein écran
| Besoin | Écrans de référence |
|---|---|
| Catalogue et panier — A02/A03 | Carte, article, panier |
| Service — A04 | Retrait au bar ou livraison en cabine |
| Parts et paiement — A05/A06/E01 | Partage, addition commune, pourboire, paiement, refus |
| Suivi — A07/E02 | Mes commandes, reçue, prête, livrée |
| Réservation — A08/A09/E03 | Activités, widget, variante portail, attente, confirmation, mes réservations |
| Annulation — A10/E03 | Annuler une réservation |
| Identité — A01 | Invité ou compte, connexion, carnet récupéré |
| Indisponibilité et reprise — A07/A09/A11 | Service indisponible, hors ligne, réservation non aboutie |
Merci de répondre aux références A01–A11 et E01–E04, en regroupant celles couvertes par le même mécanisme. Pour chaque adaptation nécessaire, préciser le livrable côté Looply et sa date de disponibilité. Séparer les frais de mise en place/développement des éventuels abonnements ou frais d’usage.
Référence · Statut · Mécanisme proposé et exemple · Limites · Coût · Délai et dépendances.
Répondez par e-mail ou dans votre document de chiffrage en reprenant ces références. Cette page ne collecte pas de réponses.
Les points à traiter en premier sont la corrélation d’identité, les parts de paiement, la transmission du service en cabine et le retour vérifiable de réservation. Ils permettent de fixer les échanges ; ils ne présument pas d’une refonte de votre moteur.