Résumé

  • RFC 3538 associait 20, 40, 60, 80 et 100 à la création ou au traitement de messages SET successifs dans le pont IOTP. Ce barème décrivait l’avancement d’une interface, pas une fraction de l’issue commerciale.
  • À 100, PRes pouvait constater une autorisation approuvée ou une capture réussie. CompletedOK pouvait ensuite devenir Failed après annulation, tandis que règlement et livraison restaient hors du champ de preuve.

Un écran d’exploitation montre une barre pleine. Que sait réellement l’opérateur ? Une demande a-t-elle été autorisée, la capture a-t-elle eu lieu, les établissements ont-ils réglé, l’entrepôt a-t-il remis le bien, l’annulation est-elle devenue impossible ? Les interfaces modernes condensent volontiers ces questions dans le mot « terminé ». Publié en juin 2003 comme document Informational, RFC 3538 répondait avec davantage de discipline : le pont entre SET et IOTP avait atteint le dernier message de sa propre séquence.

IOTP cherchait à offrir une charpente commune au commerce en ligne tout en laissant des systèmes de paiement particuliers circuler dans une Payment API. Le supplément précisait l’insertion des messages Secure Electronic Transaction dans IOTP 1.0. Les sources figées ne prouvent ni déploiement massif, ni incident nommé, ni transaction réelle. La portée historique se trouve ailleurs : une observation locale n’était pas transformée en résultat universel.

La section 8.12 donne cinq repères. Après création ou traitement de la première SET Initiation Response, PercentComplete vaut 20. PinitReq mène à 40, PinitRes à 60, PReq à 80 et PRes à 100. Consumer et Payment Handler regardent création et traitement depuis deux côtés différents. Le nombre de messages de l’initiation peut varier, mais la première réponse vaut quand même 20. Le compteur n’est donc ni une mesure de travail homogène ni une prévision de durée. C’est une carte conventionnelle de l’interface.

Le dernier message ne porte pas une signification commerciale unique. Un PRes réussi peut associer authorizationPerformed à un AuthCode approuvé, ou capturePerformed à un CapCode réussi. L’autorisation permet une étape ; la capture en est une autre. Elles partagent une enveloppe et une valeur de progression sans devenir le même événement. Pour savoir ce qui s’est passé, il faut conserver le code, pas seulement le dessin du compteur.

La machine d’état refuse elle aussi une finalité absolue. Côté Payment Handler, une transaction en cours peut atteindre CompletedOK. Pourtant, si le paiement est annulé, ChangeProcessState ou CancelPayment peut faire passer CompletedOK à Failed. L’état dit ce qu’un composant savait à un instant. Supprimer l’arête de transition revient à inventer une irréversibilité qui n’existait pas.

Le contrôle de reçu rend la limite encore plus nette. CheckPayReceipt ne vérifie pas spécialement les Payment Receipt Information ; il renvoie une réponse générale dès lors que la requête est valide. Cette répartition peut être correcte dans l’API. Elle devient trompeuse si l’interface traduit « requête bien formée » par « réalité commerciale vérifiée ». Validité de l’enveloppe, reconnaissance du reçu et corroboration du fait sont trois preuves distinctes.

La livraison ne disparaît pas dans le paiement. Pour les biens physiques, RFC 3538 recommande d’omettre les IOTP Delivery Exchanges. Une adresse d’interrogation peut être donnée, et le contrôle d’autorisation entre gestionnaires peut se faire hors IOTP. Pour les biens numériques, le texte recommande une autorisation en temps réel. Le pont peut donc finir sans déplacer un colis ni établir qu’un contenu est arrivé.

Les erreurs restent elles aussi typées. L’initiation d’enquête SET est omise, les messages d’enquête étant encapsulés dans les données IOTP. Une faute technique du pont reçoit HardError, alors qu’un échec commercial suit une autre voie. Mélanger ces origines ferait passer un refus correctement transporté pour une panne, ou un transport réussi pour une vente réussie.

Cette histoire ne reprend pas l’article RFC 3354 sur les exigences IOTP v2 et la distinction entre composition et autorisation commerciale. Elle ne reprend pas non plus RFC 3504 sur la grammaire corrigée, l’identité de transaction, l’enquête et la séparation générale paiement-règlement-livraison. Son territoire propre est concret : cinq valeurs, deux sens de succès pour PRes, un contrôle de reçu limité et une annulation après « complétion ».

La règle durable est d’exiger un dénominateur nommé pour chaque progression. Il faut garder le message exact, l’acteur qui l’a créé ou traité, le completion code et les transitions ultérieures. Alors 100 devient une preuve utile. Sans cette provenance, le nombre emprunte sa certitude à des événements qu’il n’a jamais mesurés.

Sources