🛀🏼 ✊🏻 🌋 Encore une fois sur la question des distributeurs automatiques de billets 🔣 👩🏻‍🍳 🤘🏼

Juste maintenant safinaskar m'a posé la question suivante dans une conversation personnelle:

Bonjour, j'ai vu votre article sur les distributeurs automatiques de billets habrahabr.ru/post/217337 . Ma question est: pourquoi l'interface de tous les distributeurs automatiques de billets est-elle si anti-conviviale, si identique et si «résistante», contrairement aux autres machines (disons, les machines Qiwi)? J'ai eu affaire à des distributeurs automatiques de billets Sberbank, Rosbank et My Bank (maintenant en faillite).

Dois-je bien comprendre que le logiciel pour les machines conventionnelles (par exemple Qiwi) est le logiciel le plus courant, développé de la même manière que le logiciel est généralement développé. Il est facile d'apporter des modifications au logiciel, il est écrit avec les outils habituels pour un système d'exploitation normal (par exemple Windows), l'UX est pris en compte et parfois il y a des bugs.

Et le logiciel pour les guichets automatiques est écrit une fois pour toutes (pour des raisons de sécurité), la sécurité est mise au-dessus de l'UX. Donc? Et d'où les problèmes avec UX?

J'ai l'impression que tous les guichets automatiques utilisent le même programme, n'est-ce pas?

Si je ne me trompe pas, le GAB demande d'abord une épingle, puis le montant, et ensuite seulement vérifie l'exactitude de la broche. Pourquoi donc?

Étant donné que la réponse s'est lentement développée, j'ai pensé qu'elle méritait un article séparé, d'autant plus que certains sujets ont été abordés sur lesquels je n'ai pas bien compris et que je ne voulais pas induire les gens en erreur avec des réponses incorrectes. J'espère que dans les commentaires, il y aura des clarifications et des ajouts.

Je doutais un peu si la note devait être prise - chez Habr ou giktayms. D'une part, lors du transfert d'articles, mon précédent article sur ce sujet est resté sur habrahabr. D’un autre côté, à en juger par la politique de l’administration, ils souhaitent quitter le Habr exclusivement pour ces articles, dont la majeure partie est le code du programme. Par conséquent, vous voyez mon article actuel ici.

Le développement de logiciels, comme toute autre activité, nécessite une certaine qualification. Et le développement de logiciels dans un domaine comme la finance - et plus encore. Souvenons-nous maintenant de ce qu'est une banque. Cette organisation ne développe pas de logiciel pour ses distributeurs automatiques de billets, sinon elle devrait garder le personnel pour cela. Mais le développement de scénarios est une procédure unique, il est donc inefficace. Ainsi, le développement est commandé auprès d'entreprises spécialisées.

Comme vous le savez, presque personne ne confiera ce développement à personne. Et pour changer un scénario éprouvé, vous avez besoin d'une bonne raison. Dites, le désir de la banque de fournir une gamme élargie de services par le biais de distributeurs automatiques de billets, et pas seulement des informations sur les retraits / investissements d'argent et les soldes. Pour les mêmes raisons, les scénarios misérables ne changeront que s'ils sont sûrs que cela apportera un gain financier.

J'ai l'impression que tous les guichets automatiques utilisent le même programme, n'est-ce pas?

J'utilise moi-même rarement des distributeurs automatiques de billets, mais je n'utilise pas du tout les distributeurs automatiques d'autres banques, donc je ne peux pas dire. Mais je pense que c'est le cas. Très probablement, les distributeurs automatiques de billets Wincor fonctionnant sous les protocoles NDC / DDC avec certaines extensions Wincor sont les plus courants en Russie. Parlons donc d'eux.

Je dois dire que les spécifications pour 2013 (la dernière version des spécifications que j'ai vues) ne sont pas très différentes des spécifications pour 2003. Fondamentalement, certaines opportunités douteuses sont devenues obsolètes, l'opportunité est apparue d'incorporer des pages HTML sur les écrans. Cependant, cette possibilité n'est pas encore prise en charge par nous, donc je n'en sais rien, des scénarios tout à fait tolérables sont mis en œuvre par des images. Pour ne pas dire qu'il semble si mal droit. Et puis, voulez-vous vraiment voir la publicité omniprésente également dans un guichet automatique? Elle est là, bien sûr, mais au moins pas si ennuyeuse et, en règle générale, sur l'écran principal, et non à l'intérieur du script.

Et le logiciel pour les guichets automatiques est écrit une fois pour toutes (pour des raisons de sécurité), la sécurité est mise au-dessus de l'UX. Donc? Et d'où les problèmes avec UX?

Non, il s'agit davantage de compatibilité descendante et de l'incapacité de changer radicalement le protocole de communication avec un GAB pour cette raison. De plus, il me semble que l'ATM est livré avec son logiciel: nouveau logiciel - un nouvel ATM. Puisqu'un GAB n'est pas une chose bon marché, cela peut également ralentir les changements. Bien qu'il faut admettre que les nouvelles fonctionnalités du logiciel ne sont souvent pas liées à l'interface utilisateur et que le script peut être écrit pour les anciennes versions. Mais il y a d'autres considérations. J'ai vu des guichets automatiques dont la durée de vie de l'écran CRT touche à sa fin, et si vous y montrez une image, vous obtenez un point flou. L'interface texte est meilleure. De plus, il peut toujours y avoir des distributeurs automatiques de billets qui ne savent pas comment afficher les images. Mais les zhelezyachniks peuvent mieux en parler, je ne travaille que sur la partie hôte.

Si je ne me trompe pas, le GAB demande d'abord une épingle, puis le montant, et ensuite seulement vérifie l'exactitude de la broche. Pourquoi donc?

Parce que le code PIN vérifie l' hôte. L'ATM ne peut pas effectuer cette opération (de manière générale, les protocoles NDC / DDC ont une telle opportunité, mais il faut se rappeler qu'ils sont apparus à une époque où le concept de «sécurité de l'information» n'existait pas).

Bien sûr, vous pouvez faire une demande distincte pour vérifier le code PIN au début du script, mais c'est une demande supplémentaire au serveur et augmenter le temps d'attente. Bien que cela soit utilisé - par exemple, s'il est nécessaire de diviser le script en différentes branches pour les cartes étrangères appartenant au système NSPK et les cartes complètement étrangères. Seul un hôte peut effectuer cette classification.

Pour leurs propres cartes, une demande supplémentaire peut trop ralentir le service. Par exemple, dans le réseau de guichets automatiques desservis par notre système, il existe des guichets automatiques dans lesquels, au pic de la charge, les transactions se produisent toutes les 2 minutes, à partir de différentes cartes, et, en règle générale, une transaction par carte. Ralentissez le script de moitié afin d'avertir la personne que le code PIN est erroné? C'est également une charge supplémentaire pour l'hôte - après tout, selon la norme PCI DSS, un serveur de fer séparé doit vérifier les broches, et le code PIN sera de toute façon vérifié à nouveau pendant l'opération, selon le même PCI DSS.

Entrez le code PIN avant ou après avoir sélectionné l'opération - le développeur de scénario décide des exigences de la banque. La saisie d'un code PIN au tout début est peut-être tout simplement plus familière. Et pour les cartes à puce, cela peut également être nécessaire - pour accéder aux applications de puce, vous devrez peut-être passer par une autorisation sur la puce. Mais ce sont mes hypothèses, en fait, je ne sais pas.

Encore une fois sur la question des distributeurs automatiques de billets

More articles: