Lorsqu’un consommateur passe en caisse, le montant à payer par carte bancaire s’affiche généralement sans erreur et de manière automatique sur le terminal de paiement.

Est-ce de la magie ? Non. L’information est envoyée au terminal par le logiciel .

Mais pour que cela fonctionne, il faut que les appareils se comprennent.

Pour faciliter le travail des éditeurs de logiciel et des fabricants de terminaux, un standard de communication a été développé en France : le protocole Caisse AP.

Création du protocole Caisse

Caisse-AP est un protocole utilisé en France, conçu par En France l’Association du Paiement (AP), pour faciliter la communication dans les deux sens entre les caisses enregistreuses et les terminaux de paiement conçus par des opérateurs différents.

Pendant longtemps les logiciels de caisse étaient installés sur PC, reliés à des terminaux Ingenico ou Verifone. Il a bien fallu trouver un moyen d’échanger des informations avec les terminaux sans avoir à tout réinventer avec chaque nouveau logiciel.

C’est pourquoi le protocole Caisse-AP (anciennement protocole Concert) a été conçu en partenariat avec des acteurs comme les éditeurs de logiciels de caisse, les fabricants de terminaux Ingenico et Verifone ou la plateforme de titres-restaurants Conecs.

Ce protocole n’est pas obligatoire, mais a été adopté au moins dans sa version 2 (il est actuellement disponible en version 3.2) par la plupart des éditeurs de logiciels de caisse français, d’après l’association du paiement.

Comment fonctionne le protocole ?

Le protocole Caisse-AP est conçu pour permettre l’échange de données entre la caisse et le TPE dans les deux sens.

Il prévoit tout d’abord que l’application de caisse puisse être capable d’agir par des « messages aller » notamment sur :

  • Le choix de l’application du terminal (cela dépend de l’accord des fabricants de terminaux).
  • La transaction (débit, crédit pour les remboursements, annulation, etc.).
  • La télécollecte.
  • L’impression du ticket.

Quel « message retour » ?

De très nombreux cas sont prévus dans le protocole ; on n’en mentionnera que quelques-uns :

  • Le montant payé : on pourrait penser que le montant est le même, mais en cas d’autorisation partielle, le montant retourné sera différent. Par exemple : le solde d’une carte est de 30 euros et le montant de 50 €. La caisse pourra autoriser un débit partiel de 30 euros et laisser le client régler le reste avec un autre moyen de paiement.
  • Le numéro de la carte (PAN) et son code d’identification (AID), qui renseigne sur le type de carte et son origine géographique.
  • L’application utilisée : même si le terminal interdit le choix de l’application par la caisse, il enverra un message de retour pour indiquer la version de l’application utilisée.
  • La devise utilisée. Confirmation utile dans les zones frontalières ou aéroportuaires où l’on jongle entre les devises.

Les matériels et logiciels compatibles

Ce protocole ne fonctionnera qu’avec certains terminaux achetés en France. C’est le cas de tous les terminaux Ingenico ou Verifone. Les terminaux PAX peuvent aussi être compatibles si le monéticien a lui-même implémenté le protocole, ce qui est le cas avec les terminaux de Smile and Pay et de Yavin.

Du point de vue pratique, Caisse-AP peut communiquer en principe avec tout type de caisse enregistreuse (PC, tablette Android, iPad), à partir du moment où le terminal est sur le même réseau que la caisse.

Il fonctionne avec les applications de paiement installées sur les terminaux, compatibles avec le réseau CB du GIE cartes bancaires français. Cela signifie que l’application de paiement pourra interpréter correctement l’information envoyée par le logiciel de caisse. Il s’agit par exemple des applications CB, AMEX, CONECS, DINER’S etc.

Les éditeurs de logiciel peuvent utiliser des versions anciennes du protocole Caisse, c’est pourquoi ils ne sont pas forcément répertoriés sur le site de l’AP. Vous pouvez cependant consulter leur site pour voir si votre éditeur a implémenté la dernière version.

Est-il indispensable ?

Non dans l’absolu. La création de ce protocole a cependant grandement facilité la communication entre matériels et de logiciels conçus par différents acteurs, puisque les éditeurs ont pu se baser sur un standard conçu avec les fabricants de terminaux.

Point important : un tel protocole universel n’est utile que dans le cadre d’un système ouvert.

Si un éditeur de logiciel veut que celui-ci soit compatible avec des terminaux Ingenico ou Verifone, il est plus simple de se baser sur ce protocole. Inversement un fabricant de terminaux qui arrive sur le marché français a intérêt à adopter ce protocole.

Le commerçant a quant à lui intérêt à choisir un terminal compatible s’il a l’intention d’utiliser un logiciel de caisse ouvert développé en France.

Dans les systèmes fermés, c’est-à-dire lorsqu’un acteur gère en même temps la fabrication de terminaux de paiement ou de point de vente, ainsi que la création de logiciels de caisse adaptés au matériel qu’il commercialise, il n’est pas nécessaire d’utiliser un protocole de caisse universel. Un protocole « maison » est plus adapté.

Exemple de systèmes fermés ou semi-fermés qui n’ont pas besoin du protocole Caisse AP : la caisse enregistreuse de SumUp ou la caisse Square. Ces deux éditeurs commercialisent en effet leurs propres terminaux et logiciels de caisse.

Ces fabricants permettent toutefois à certains éditeurs de logiciels d’utiliser leurs terminaux, mais dans ce cas l’éditeur du logiciel doit travailler lui-même à l’implémentation du protocole du fabricant. Pour pouvoir interagir avec un terminal comme le SumUp Air, il faudra travailler directement avec le fabricant du terminal.

Dans tous les cas, le commerçant doit vérifier que son logiciel de caisse et son terminal sont compatibles.