# Cas d’utilisation

# Préface

Cette section contient des informations sur la façon d'utiliser ce document.

# Conventions utilisées dans ce document

Les conventions suivantes sont utilisées dans ce document pour identifier les types d'informations spécifiques.

Type d'information	Convention	Exemple
Éléments de l'API, tels que les ressources	Gras	/authorization
Variables	Italique entre accolades	{ID}
Termes du glossaire	Italique à la première occurrence ; défini dans Glossaire	Le but de l'API est de permettre des transactions financières interopérables entre un Payeur (un payeur de fonds électroniques dans une transaction de paiement) situé dans un FSP (une entité qui fournit un service financier numérique à un utilisateur final) et un Bénéficiaire (un bénéficiaire de fonds électroniques dans une transaction de paiement) situé dans un autre FSP.
Documents de référence	Italique	Les informations utilisateur ne devraient, en général, pas être utilisées par les déploiements de l'API ; les mesures de sécurité détaillées dans Signature API et Chiffrement API devraient être utilisées à la place.

# Informations sur la version du document

Version	Date	Description des modifications
1.0	2018-03-13	Version initiale

# Introduction

L'objectif de ce document est de définir un ensemble de cas d'utilisation pouvant être mis en œuvre à l'aide de l’Open API pour l’interopérabilité FSP (appelée ci-après l’API). Les cas d’utilisation référencés dans ce document donnent un aperçu des flux de traitement des transactions et des règles métier de chaque étape ainsi que des conditions d’erreur pertinentes.

Le but principal de l’API est de permettre le transfert de transactions financières entre un Fournisseur de Services Financiers (FSP) et un autre.

Il convient de noter que l’API n’est responsable que de l’échange de messages entre les FSP et un switch lorsque qu’une transaction entre FSPs est initiée par un Utilisateur Final dans l’un des FSPs. Ceci peut se produire dans deux scénarios :

• Un scénario bilatéral dans lequel les FSPs communiquent directement entre eux

• Un scénario basé sur Switch dans lequel toutes les communications passent par un Switch

La réconciliation, la compensation et le règlement après les transactions en temps réel sont hors du champ de l’API. De plus, la recherche de comptes est prise en charge par l’API, mais dépend de l’implémentation dans un marché local dans lequel un tiers ou un Switch fournirait ces services. Par conséquent, la nécessité de processus d’intégration efficaces et de règles du système appropriées doit être prise en compte lors de la mise en œuvre des cas d’utilisation.

# Spécification Open API pour l’interopérabilité FSP

La spécification Open API pour l’interopérabilité FSP comprend les documents suivants.

# Documents généraux

• Glossaire

# Documents logiques

• Modèle de données logique

• Schémas de transaction génériques

• Cas d’utilisation

# Documents de liaison REST asynchrone

• Définition API

• Règles de liaison JSON

• Règles du système

# Intégrité des données, confidentialité et non-répudiation

• Meilleures pratiques PKI

• Signature

• Chiffrement

# Résumés des cas d’utilisation

Les schémas de transaction génériques suivants sont présentés dans Schémas de transaction génériques pour réduire la duplication des descriptions de chaque cas d’utilisation. Ces modèles résument les flux de transaction communs et les fonctions partagées des cas d'utilisation pertinents.

• Transaction initiée par le payeur

  • Dans une transaction initiée par le payeur, c’est le Payeur (c’est-à-dire celui qui effectue le paiement électronique) qui initie la transaction.

    Ce modèle doit être utilisé chaque fois qu’un Payeur souhaite transférer des fonds à une autre partie dont le compte n’est pas situé dans le même FSP.

• Transaction initiée par le bénéficiaire

  • Dans une transaction initiée par le bénéficiaire, c’est le Bénéficiaire (c’est-à-dire le receveur des fonds électroniques) qui initie la transaction.

    Ce modèle doit être utilisé chaque fois qu’un bénéficiaire souhaite recevoir des fonds d’une autre partie dont le compte n’est pas situé dans le même FSP.

• Transaction initiée par le bénéficiaire avec OTP

  • Une transaction initiée par le bénéficiaire avec mot de passe à usage unique (OTP) est similaire à la transaction initiée par le bénéficiaire, mais les informations de transaction (y compris les frais et les taxes) et l'approbation du payeur sont affichées ou saisies sur un appareil du bénéficiaire.

  • Ce modèle doit être utilisé lorsque le bénéficiaire souhaite recevoir des fonds d'une autre partie dont le compte n’est pas dans le même FSP, et que les informations et l’approbation sont gérées sur l'appareil du bénéficiaire.

• Transactions groupées

  • Dans une transaction groupée, c’est le payeur (l’expéditeur de fonds) qui initie plusieurs transactions vers plusieurs bénéficiaires situés potentiellement dans différents FSPs.

  • Le modèle doit être utilisé chaque fois qu’un payeur souhaite transférer des fonds à plusieurs bénéficiaires lors de la même transaction. Les bénéficiaires peuvent être dans différents FSPs.

Il est recommandé de lire tous les schémas de transaction génériques avant de lire les cas d'utilisation. Pour plus d’informations, voir Schémas de transaction génériques.

Chaque cas d’utilisation décrit des variations et des considérations spéciales pour le schéma de transaction générique auquel il se réfère. Les cas d’utilisation sont présentés dans le Tableau 1 ci-dessous :

# Tableau 1

Nom du cas d’utilisation	Description
P2P	Ce cas décrit le processus métier et les règles selon lesquelles un Utilisateur Final initie une transaction pour envoyer de l’argent à un autre Utilisateur Final n’appartenant pas au même FSP que le Payeur. C’est généralement une transaction à distance où Payeur et Bénéficiaire ne sont pas au même endroit.
Dépôt d'espèces initié par l’agent	Ce cas décrit le processus métier et les règles où un client demande à un agent d’un autre FSP d’effectuer un dépôt sur son compte. Il s’agit généralement d’une transaction en face à face où le client et l’agent sont au même endroit.
Retrait d'espèces initié par l’agent	Ce cas décrit le processus métier et les règles où un client demande qu’un agent d’un autre FSP effectue un retrait de son compte. Il s’agit généralement d’une transaction en face à face où le client et l’agent sont au même endroit.
Retrait d'espèces initié par l’agent Autorisé sur POS	Ce cas décrit le processus métier où un client demande à un agent d’un autre FSP d’effectuer un retrait. L’agent initie la transaction via un terminal de point de vente (POS) et le client saisit un OTP sur le POS pour l’autoriser. Alternativement, l’agent peut utiliser le POS pour scanner un QR code généré par l’application mobile du client.
Retrait d'espèces initié par le client	Ce cas décrit le processus métier où un client enregistré initie un retrait d’espèces via un agent n’appartenant pas à son FSP. C’est également typiquement une transaction en face à face.
Paiement marchand initié par le client	Ce cas décrit le processus métier où un utilisateur final initie une transaction d’achat pour payer un marchand n’étant pas dans le même FSP. C’est généralement une transaction en face à face lors d’un achat en magasin. Une variante est le paiement en ligne où un QR code est généré et affiché sur une page web, puis scanné par le client pour compléter la transaction.
Paiement marchand initié par le marchand	Ce cas décrit le processus où un commerçant initie une demande de paiement vers un client ; le client révise le montant et confirme via authentification sur son propre appareil.
Paiement marchand initié par le marchand Autorisé sur POS	Ce cas décrit le processus où un marchand initie une demande de paiement ; le client révise la demande sur le terminal du marchand et autorise le paiement par OTP ou QR code. Les informations d’authentification du client sont envoyées du FSP du bénéficiaire vers le FSP du payeur pour authentification.
Retrait d'espèces initié par DAB	Ce cas décrit le processus où un DAB lance une demande de retrait sur un compte client. Le client pré-génère un OTP pour le retrait et l’utilise sur le DAB pour lancer l’opération. Le FSP du payeur valide l’OTP reçu pour authentification.
Paiements groupés	Paiements groupés est utilisé lorsqu’une organisation ou une entreprise effectue des paiements, par exemple, de l’aide ou des salaires à plusieurs bénéficiaires ayant des comptes dans différents FSPs. L’organisation peut grouper les transactions pour faciliter l’envoi et la validation avant exécution. Il est aussi possible de suivre les résultats des transactions individuelles après exécution.
Remboursement	Ce cas décrit le flux métier pour rembourser une transaction d’interopérabilité complétée.

Tableau 1 – Résumé des cas d’utilisation

# Cas d’utilisation

Cette section illustre les façons dont l’API peut être utilisée via les cas d’utilisation identifiés dans le Tableau 1 – Résumé des cas d’utilisation.

Pour chaque cas d’utilisation, les éléments suivants sont présentés :

• Description du cas d’utilisation
• Référence au schéma générique
• Acteurs et rôles
• Ajouts au schéma de transaction générique
• Conditions d’erreur pertinentes

(La traduction complète du document est très volumineuse. Veuillez indiquer si vous souhaitez poursuivre avec la traduction de l’intégralité du contenu ci-dessous, ou d’une partie spécifique.)