# Modèles de Transactions Génériques

# Préface

Cette section contient des informations sur la manière d'utiliser ce document.

# Conventions Utilisées dans Ce Document

Les conventions suivantes sont utilisées dans ce document pour identifier les différents types d’information :

Type d’Information Convention Exemple
Éléments de l’API, comme les ressources Gras /authorization
Variables Italique entre accolades {ID}
Termes du glossaire Italique à la première occurrence ; défini dans le Glossaire L'objectif 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 destinataire de fonds électroniques dans une transaction de paiement) situé dans un autre FSP.
Documents de référence Italique Les informations utilisateurs ne devraient généralement pas être utilisées par les déploiements d’API ; les mesures de sécurité détaillées dans Signature API et Chiffrement API doivent être employées.

# Informations sur la Version du Document

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

# Introduction

Ce document présente les quatre modèles de transactions génériques pris en charge dans une version logique de l’API d’Interopérabilité. De plus, tous les services logiques faisant partie de l’API sont présentés dans les grandes lignes.

# Spécification Open API pour l'Interopérabilité des FSP

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

# Documents Logiques

# Documents de Liaison REST Asynchrone

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

# Documents Généraux


# Services logiques de l’API

L’API d’Interopérabilité se compose de plusieurs ressources d’API logiques. Chaque ressource définit un ou plusieurs services utilisables par les clients pour se connecter à un serveur ayant implémenté l’API. Cette section présente ces services.

Note: Les services API identifiés dans cette section peuvent ne pas s’appliquer (et donc ne pas apparaître) dans les modèles de transactions génériques identifiés dans Modèles de Transactions Génériques.

Par exemple, certains services servent à la fourniture d'informations, font partie des cas d'erreurs ou servent à la récupération d'informations non nécessaires dans un modèle de transaction générique.


# Fonctionnalités Communes

Cette section présente des fonctionnalités utilisées par plusieurs ressources ou services logiques de l'API.

# Adressage des parties

Une Partie est une entité telle qu’un individu, une entreprise, une organisation ayant un compte financier dans un des FSPs. Une partie est identifiée par une combinaison d’un Type d’ID et d’un ID, et éventuellement aussi par un sous-type ou un sous-ID. Quelques exemples de combinaisons Type d’ID et ID :

  • Type d’ID : MSISDN, ID : +123456789

  • Type d’ID : Email, ID : john@doe.com

# Interledger

L’API inclut une prise en charge de base du protocole Interledger (ILP) en définissant une mise en œuvre concrète du protocole « Interledger Payment Request »1 (opens new window)(ILP) dans les ressources logiques Devis et Transferts. Plus de détails sur le protocole ILP sont disponibles sur le site du projet Interledger2 (opens new window), dans le livre blanc Interledger3 (opens new window) et dans la spécification d’architecture Interledger4 (opens new window).


# Ressource API Participants

Dans l’API, un Participant est l’équivalent d’un FSP qui participe à un scheme d’interopérabilité. L’objectif principal de la ressource API logique Participants est de permettre aux FSPs de savoir dans quel autre FSP se situe une contrepartie dans une transaction financière interopérable. Il existe également des services définis pour que les FSPs puissent fournir des informations à un système commun.

# Requêtes

Cette section identifie les requêtes de services de l’API logique qui peuvent être envoyées d’un client à un serveur.

# Recherche d’Informations sur un Participant

La requête logique Recherche d’Informations sur un Participant est utilisée par un FSP pour demander à un autre système (qui peut être un autre FSP ou un système commun) des informations concernant dans quel FSP se situe une contrepartie dans une transaction financière interopérable.

# Création d’Informations sur un Participant

La requête logique Création d’Informations sur un Participant est utilisée pour fournir des informations sur le FSP dans lequel se trouve une partie.

# Création d’informations groupées sur les participants

La requête logique Création d’informations groupées sur les participants est utilisée pour fournir des informations sur le(s) FSP(s) dans le(s)quel(s) se trouvent une ou plusieurs parties.

# Suppression d’Informations sur un Participant

La requête logique Suppression d’Informations sur un Participant est utilisée pour retirer des informations concernant le FSP dans lequel se trouve une partie.


# Réponses

Cette section identifie les réponses de service logique de l’API pouvant être renvoyées à un client par un serveur.

# Retour des informations sur le participant

Réponse utilisée pour retourner des informations suite aux requêtes Recherche d’Informations sur un Participant, Création d’Informations sur un Participant et Suppression d’Informations sur un Participant.

# Retour des informations groupées sur les participants

Réponse utilisée pour retourner les informations suite à la requête Création d’informations groupées sur les participants.


# Réponses d’Erreur

Cette section identifie les réponses d’erreur pouvant être renvoyées à un client par un serveur.

# Erreur de retour des informations sur le participant

Réponse d’erreur utilisée en cas de problème lors des requêtes Recherche d’Informations sur un Participant, Création d’Informations sur un Participant et Suppression d’Informations sur un Participant.

# Erreur de retour des informations groupées sur les participants

Réponse d’erreur utilisée en cas de problème lors de la requête Création d’informations groupées sur les participants.


# Ressource API Parties

Dans l’API, une Partie est un individu, une entreprise, une organisation ou une entité similaire possédant un compte financier dans l’un des FSP. L’objectif principal de la ressource API logique Parties est de permettre aux FSP de récupérer des informations sur une contrepartie dans une transaction interopérable (nom, date de naissance, etc.).

# Requêtes

# Recherche d’Informations sur une Partie

La requête logique Recherche d’Informations sur une Partie est utilisée par un FSP pour demander à un autre FSP des informations concernant une contrepartie dans une transaction financière interopérable.


# Réponses

# Retour des informations sur la partie

Réponse utilisée pour retourner des informations suite à la requête Recherche d’Informations sur une Partie.


# Réponses d’Erreur

# Retour d'erreur sur les informations de la partie

Réponse d’erreur utilisée pour retourner des informations d’erreur suite à la requête Recherche d’Informations sur une Partie.


# Ressource API : demandes de transaction

Dans l’API, une Demande de Transaction est une demande d’un Bénéficiaire vers un Payeur pour transférer des fonds électroniques au Bénéficiaire, que le Payeur peut accepter ou refuser. L’objectif de la ressource logique Demandes de transaction est qu’un FSP du bénéficiaire envoie la demande de transfert au FSP du payeur.

# Requêtes

# Effectuer une demande de transaction

La requête Effectuer une demande de transaction sert à envoyer une demande de transfert d’un FSP bénéficiaire vers un FSP payeur, c’est-à-dire à demander si le payeur accepte ou refuse la transaction.

# Récupérer des Informations sur une Demande de Transaction

Cette requête est envoyée du FSP du bénéficiaire vers le FSP du payeur pour récupérer des informations sur une demande antérieure.


# Réponses

# Retour des informations sur la demande de transaction

Réponse utilisée pour retourner des informations suite aux requêtes Effectuer une demande de transaction ou Récupérer des Informations sur une Demande de Transaction.


# Réponses d’Erreur

# Erreur de retour de la demande de transaction

Réponse d’erreur utilisée pour retourner des informations d’erreur concernant les requêtes Effectuer une demande de transaction ou Récupérer des Informations sur une Demande de Transaction.


# Ressource API Devis

Dans l’API, un Devis représente le prix pour effectuer une transaction financière interopérable entre un FSP payeur et un FSP bénéficiaire. L’objectif principal de la ressource logique Devis est que le FSP payeur demande au FSP bénéficiaire de calculer sa part du devis.

# Requêtes

# Calculer un devis

La requête Calculer un devis est envoyée par un FSP payeur pour demander au FSP bénéficiaire de calculer sa part du devis. Le FSP bénéficiaire devrait aussi générer le paquet ILP et la condition (voir Interledger) à la réception de la demande.


# Récupérer des Informations sur un Devis

Cette requête permet au FSP payeur de demander des informations sur un devis déjà émis.


# Réponses

# Retour des informations sur le devis

Réponse utilisée pour retourner des informations suite aux requêtes Calculer un devis ou Récupérer des Informations sur un Devis.


# Réponses d’Erreur

# Erreur de retour du devis

Réponse d’erreur utilisée pour retourner des informations d’erreur concernant les requêtes Calculer un devis ou Récupérer des Informations sur un Devis.


# Ressource API Autorisations

Dans l’API, une Autorisation est une approbation d’un payeur pour effectuer une transaction interopérable par saisie des identifiants applicables dans le système FSP du bénéficiaire. Exemple : un payeur effectuant une opération sur un DAB géré par un autre FSP. L’objectif principal de la ressource logique Autorisations est que le FSP payeur demande au FSP bénéficiaire de solliciter la saisie des identifiants au payeur.

# Requêtes

# Exécuter une Autorisation

La requête Exécuter une Autorisation est envoyée par un FSP payeur au FSP bénéficiaire pour demander la saisie des identifiants permettant d’approuver la transaction interopérable.


# Réponses

# Retour du résultat d'autorisation

Réponse utilisée pour retourner des informations suite à la requête Exécuter une Autorisation.


# Réponses d’Erreur

# Retour d'erreur d'autorisation

Réponse d’erreur utilisée pour retourner les erreurs concernant la requête Exécuter une Autorisation.


# Ressource API Transferts

Dans l’API, un Transfert désigne un transfert de fonds hop-to-hop via ILP (voir Interledger pour plus d’informations).

Le transfert contient également des informations sur la transaction interopérable de bout en bout. L’objectif principal de la ressource logique Transferts est qu’un FSP ou le Switch demande au prochain acteur de la chaîne ILP d’effectuer le transfert.

# Requêtes

# Effectuer un Transfert

La requête Effectuer un Transfert permet à un FSP ou au Switch de demander au prochain acteur de la chaîne de réserver le transfert correspondant à la transaction.

# Récupérer des Informations sur un Transfert

Permet de demander au prochain acteur des informations concernant le transfert concerné.


# Réponses

# Retour des informations sur le transfert

Réponse utilisée pour retourner des informations suite aux requêtes Effectuer un Transfert ou Récupérer des Informations sur un Transfert. Suite à la réception de cette réponse, le FSP ou Switch doit valider l’exécution (voir Interledger) et valider le transfert réservé si la validation est positive.


# Réponses d’Erreur

# Erreur de retour du transfert

Réponse d’erreur utilisée pour retourner des erreurs liées aux requêtes Effectuer un Transfert ou Récupérer des Informations sur un Transfert.


# Ressource API Transactions

Dans l’API, une Transaction est une transaction financière interopérable de bout en bout entre le FSP du payeur et celui du bénéficiaire. L’objectif principal de la ressource logique Transactions est que le FSP payeur demande des informations de bout en bout au FSP bénéficiaire, par exemple pour obtenir un code ou un jeton à utiliser pour retirer un service ou un produit.

# Requêtes

Permet d’identifier les requêtes de services API logiques pouvant être envoyées d’un client à un serveur.

# Récupérer des Informations sur une Transaction

La requête Récupérer des Informations sur une Transaction permet au FSP payeur de demander au FSP bénéficiaire des informations sur une transaction effectuée précédemment (en utilisant la ressource logique Transferts, voir API Ressource Transferts).


# Réponses

# Retour des informations sur la transaction

Réponse utilisée pour retourner des informations suite à la requête Récupérer des Informations sur un Transfert.


# Réponses d’Erreur

# Erreur de retour des informations sur la transaction

Réponse d’erreur utilisée pour retourner des erreurs liées à la requête Récupérer des Informations sur un Transfert.


# Ressource API : devis groupés

Dans l’API, un devis groupé désigne un ensemble de devis individuels (voir la section Ressource API Devis) pour effectuer plusieurs transactions interopérables de FSP payeur à FSP bénéficiaire.

L’objectif principal de la ressource Devis groupés est que le FSP payeur demande au FSP bénéficiaire de calculer sa part du devis groupé.

# Requêtes

# Calculer un devis groupé

La requête Calculer un devis groupé est utilisée par un FSP payeur pour demander au FSP bénéficiaire de calculer sa part du devis pour effectuer plusieurs transactions interopérables.

Le FSP bénéficiaire devrait aussi générer le paquet ILP et la condition pour chaque devis.

# Récupérer des informations sur un devis groupé

Permet à un FSP payeur de demander à un FSP bénéficiaire des informations sur un devis groupé précédemment envoyé.


# Réponses

# Retour des informations sur le devis groupé

Réponse utilisée pour retourner des informations suite aux requêtes Calculer un devis groupé ou Récupérer des informations sur un devis groupé.


# Réponses d’Erreur

# Erreur de retour du devis groupé

Réponse d’erreur utilisée pour retourner des erreurs liées aux requêtes Calculer un devis groupé ou Récupérer des informations sur un devis groupé.


# Ressource API : transferts groupés

Dans l’API, un transfert groupé est un ensemble de transferts ILP hop-to-hop (voir Interledger), chacun correspondant à une transaction. Les transferts contiennent aussi les détails des transactions de bout en bout.

La ressource logique Transferts groupés permet à un FSP ou au Switch de demander au prochain acteur d’effectuer les transferts nécessaires.

# Requêtes

# Effectuer un transfert groupé

Permet à un FSP ou Switch de demander au prochain acteur de réserver les transferts nécessaires à une transaction financière interopérable.

# Récupérer des informations sur un transfert groupé

Permet de demander des informations sur un transfert donné.


# Réponses

# Retour des informations sur le transfert groupé

Réponse pour retourner les informations suite aux requêtes Effectuer un transfert groupé ou Récupérer des informations sur un transfert groupé.

À réception, le FSP ou le Switch doit valider les fulfilments et valider les transferts réservés si la validation est réussie.


# Réponses d’Erreur

# Erreur de retour du transfert groupé

Réponse utilisée pour retourner des erreurs concernant Effectuer un transfert groupé ou Récupérer des informations sur un transfert groupé.


# Modèles de Transactions Génériques

Cette section expose les trois principaux modèles de transactions définis dans l’API d’Interopérabilité :

Chaque modèle décrit comment transférer des fonds d’un payeur dans un FSP à un bénéficiaire dans un autre FSP.

Les modèles Transaction initiée par le payeur et Transaction initiée par le bénéficiaire concernent chacun un transfert unique entre un payeur et un bénéficiaire. La différence principale porte sur l’initiateur de la transaction.

Le modèle Transaction groupée est utilisé lorsqu’un seul payeur souhaite transférer des fonds à plusieurs bénéficiaires, éventuellement dans des FSP différents, en une seule opération.

Cette section fournit également des informations sur le modèle alternatif Transaction initiée par le bénéficiaire avec OTP. De plus, elle couvre dans les grandes lignes tous les services logiques inclus dans l’API.


← Cas d’utilisation →

Attribution-NoDerivatives 4.0 International (CC BY-ND 4.0) | Ericsson, Huawei, Mahindra-Comviva, Telepin, and the Bill & Melinda Gates Foundation