L'article est de peu d'utilité pour les pays de la CEI, mais il peut vous plaire
J'ai beaucoup travaillé ces derniers temps avec l'API de différentes banques. Il y a une raison à cela - une nouvelle directive appelée PSD2 (Directive révisée sur les services de paiement). Je vais te parler d'elle.
Entrée
Tout a commencé avec des entreprises comme PayPal. Vous vous inscrivez sur le site PayPal, celui-ci, à son tour, récupère votre carte de crédit, en retire de l'argent lorsque cela est nécessaire, accumule des franchises dans ses comptes, puis, le jour fixé, expédie la totalité du nième montant d'argent sur le compte de la boutique en ligne. Ainsi, votre carte de crédit reste en sécurité, la boutique en ligne économise de l'argent, ce qui signifie que vous économisez de l'argent. Il semble que tout le monde va bien.
D'un autre côté, une question logique se pose: le magasin perd-il des clients qui n'ont pas de carte de crédit ou ne veulent pas en avoir pour des achats individuels sur Internet?!
Et ici, de petites entreprises entrent en scène, qui ne mettent pas en service votre carte de crédit, mais votre compte bancaire. Pas même ça, votre banque en ligne! Maintenant, vous n'avez pas besoin de carte de crédit, vous n'avez pas besoin de PayPal, vous n'avez même plus besoin d'effectuer de virement. Vous entrez simplement votre nom d'utilisateur et votre mot de passe sur le site Web de la boutique, et l'intermédiaire fera le reste pour vous.
Vous entrez des données dans le formulaire sur le site Web de la boutique en ligne, l'intermédiaire saisit simultanément les mêmes données dans le formulaire de la banque en ligne, puis à l'aide des mêmes séléniums clique ici et là dans votre banque en ligne, effectuant ainsi un virement si nécessaire. Plus précisément, à ses frais, d'où il envoie ensuite tous les fonds sur les comptes des magasins une fois toutes les deux semaines.
Bien sûr, avec tout changement dans la page de la banque en ligne, tout cela cesse immédiatement de fonctionner, ce qui agace les gens. Mais les banques changent rarement quoi que ce soit, donc cela arrive rarement.
Une autre chose est que certaines banques n'aiment pas vraiment un tel trou de sécurité, elles essaient donc de bloquer ces intermédiaires. Le succès et la manière exacte dont ils le font peuvent être discutés pendant longtemps, mais l'article traîne en longueur.
De manière générale, à la demande des travailleurs et des travailleurs de ces systèmes de paiement intermédiaires, le Conseil de l'Europe est allé de l'avant et a émis une directive obligeant les banques à créer une API qui autoriserait tout ce qui était fait avec la banque en ligne auparavant, mais maintenant uniquement à l'aide de demandes. Les banques, bien sûr, étaient très contrariées, et même sans ces régulateurs, elles ont suffisamment de règles à suivre, mais il n'y a rien à faire - elles doivent être créées.
Naturellement, les banques ne sont pas non plus d'une douzaine timide et sabotent cette loi de différentes manières, car elles n'en tirent aucun avantage. Oui, il y a des exceptions lorsque tout fonctionne immédiatement comme il se doit et que la documentation est en place, mais dans la plupart des cas, ce n'est qu'un massacre de tronçonneuse au Texas, juste pas une tronçonneuse et pas au Texas, mais des courriels, des appels et des malédictions devant l'écran de votre moniteur au bureau.
Ils sabotent magistralement. Certains ne traduisent tout simplement pas leur documentation. Autrement dit, il est, pour ainsi dire, mais ce n'est pas, pour ainsi dire, car aucun Google n'aidera à traduire 90 pages de espagnol technique pour une raison quelconque. Les Espagnols vivent généralement dans leur propre vide et ne reconnaissent pas qu'il existe une sorte de langue internationale autre que l'espagnol. Beaucoup plus présentent la documentation sous la forme d'un fichier
YAML , dans lequel il n'y a pas un seul commentaire, ce qui n'est pas clair où envoyer, les noms des champs n'ont pas de normes, et vous ne pouvez pas savoir quoi signer avec quel certificat ou ne rien signer.
Le haut du sabotage est la page de documentation, où seuls les points finaux de l'API sont indiqués, mais en principe il n'y a pas d'en-tête ou de corps avec une description. Même une demande POST ou GET n'est pas indiquée. Bien sûr, le service juridique court après de tels gars, disant que les plaintes adressées à l'autorité de contrôle ne peuvent pas entraîner une amende, mais à l'avenir, cela peut conduire à une attention excessive à cette banque. Dans la plupart des cas, cela aide, mais le temps passe.
Je connaissais les conneries, maintenant vous pouvez écrire sur la loi elle-même.
Qu'est-ce que la PSD2?
Il s'agit d'une directive émise par la Commission européenne pour améliorer le marché des paiements en ligne, ainsi que pour accroître la sécurité de ces paiements.
En fait, il y avait encore un PSD, mais il réglementait simplement les paiements entre les États de l'UE, sans réglementer les paiements en ligne. Bien que soient alors les paiements en ligne en 2007m.
Ils ont pris le PSD mentionné comme base et y ont attaché une douzaine de chapitres avec le beau nom «open banking» (open banking). Ces dix chapitres sont devenus un casse-tête pour les banques et une joie pour les systèmes de paiement (en théorie, en fait, les banques ont aussi fait mal à la tête aux payeurs, afin de ne pas en souffrir.)
PSD2 réglemente également la sécurité des clients, en indiquant comment et de quelle manière les demandes doivent être transmises, quels certificats utiliser et ce qui peut être demandé à la banque et ce qui ne l'est pas. Autrement dit, pour le paiement, vous pouvez demander un prénom et un nom, ainsi qu'une liste de comptes d'utilisateurs, mais vous n'obtiendrez rien d'autre, même si vous en demandez beaucoup.
Vous devez maintenant demander un jeton à la banque, vous enregistrer en tant qu'organisation, qui peut et doit effectuer toutes les actions au nom du client, en plus vous devez avoir une clé secrète, etc., etc. En général, la sécurité a en fait considérablement augmenté. Eh bien, la responsabilité des deux parties aussi.
Mais ici, les banques sont libres d'ajouter leurs propres couches de sécurité. Par exemple, les banques vous permettent de saisir des données client uniquement sur les pages de la banque. Autrement dit, dans tous les cas, vous devrez rediriger l'utilisateur vers la page de la banque, puis vous le renvoyer (d'accord, Selenium peut également vous aider, mais maintenant les banques peuvent vous envoyer des vœux enflammés et refuser l'accès à leur API si quelque chose ne va pas).
D'accord, maintenant sur l'évidence, et pas le cas, les avantages
Comme je l'ai dit plus haut, la sécurité a considérablement augmenté. Désormais, les systèmes de paiement n'inventent pas de vélos et n'interagissent pas avec les API hétéroclites des banques, mais se connectent à des API plus ou moins standardisées, donc tout va bien avec la sécurité.
Maintenant, si vous êtes un système de paiement, par exemple en Estonie, vous pouvez utiliser l'API des banques européennes pour accepter les paiements des clients européens. Et pour cela, il vous suffit de vous inscrire en tant qu'institution financière, de lire une centaine de documents et de mettre tout cela en œuvre dans votre système. Cependant, la plupart de la documentation sera en anglais, en plus, vous aurez un support plus ou moins distinct de la banque.
Et aussi, si vous êtes une banque en dehors de l'UE, vous pouvez rejoindre cette banque ouverte et vos clients pourront payer avec les systèmes de paiement européens.
Eh bien, ici, vous pouvez également écrire des avantages que si vous n'êtes pas une grande entreprise pour casser les prix des transferts et partager une partie avec les banques, vous pouvez maintenant librement faire la même chose qu'une grande entreprise, car le droit d'accéder aux paiements maintenant tout le monde est égal.
Maintenant sur les inconvénients
Il existe une directive, mais l'API dans sa version de travail ne l'est pas. La situation est assez courante même maintenant, un an après que les banques ont commencé à travailler sur la mise en œuvre (et, eh bien, oui, elles auraient dû commencer à travailler ...).
Les API ne sont pas complètement unifiées, tout comme le processus de paiement. Autrement dit, vous ne pouvez pas créer quelque chose d'universel pour toutes les banques, vous devez ajuster la fonctionnalité des demandes pour chaque banque séparément, ce qui ralentit considérablement le développement.
Même la même banque peut avoir des API différentes dans différents pays. Parce que chaque pays a ses propres organismes de réglementation qui ajoutent une sorte de «réglementation» au processus. Là, vous avez besoin de jetons supplémentaires, là, vous devez autoriser l'utilisateur trois fois, il y a autre chose ...
Eh bien, maintenant, votre entreprise du système de paiement dépend complètement de la banque, dont les serveurs peuvent soudainement tomber en panne, et bien que toute la machine bureaucratique fonctionne et les redémarre, cela peut prendre un jour ou deux, ce qui privera vos revenus décents. Dans ce cas, vous ne pouvez pas présenter quelque chose à la banque.
C'est tout.