Rechargement cartes pré-payées

Transcription

BDDF
PJ22041 – Rechargement cartes pré-payées
Rechargement de carte pré_payée
le 21/05/09
Page : 1 / 17
Document d’Architecture Groupe
BDDF
Sommaire
1.
ARCHITECTURE FONCTIONNELLE .............................................................. 3
1.1.
1.2.
1.3.
Prise en compte de la stratégie et du contexte ............................................................................... 3
Processus métier/fonction .............................................................................................................. 5
Description du niveau système d’information .................................................................................. 9
1.3.1.
1.3.2.
1.3.3.
1.3.4.
1.4.
Description de l’architecture fonctionnelle......................................................................................11
1.4.1.
1.4.2.
1.4.3.
2.
Positionnement dans le plan d’urbanisme ...............................................................................................................................9
Positionnement dans le modèle fonctionnel du Métier ............................................................................................................9
Modèle fonctionnel du projet ..................................................................................................................................................10
Modèle informationnel du projet .............................................................................................................................................11
Schéma synthétique ..................................................................................................................... Erreur ! Signet non défini.
Schéma synthétique ...............................................................................................................................................................12
Description (texte) ...................................................................................................................................................................13
ARCHITECTURE TECHNIQUE ET SERVICES ................................................. 14
2.1.
2.2.
2.2.1.
2.2.2.
Description de l’architecture technique ..........................................................................................14
Flux ..............................................................................................................................................16
Liste des Flux ..........................................................................................................................................................................16
Schéma de cinématique des Flux ..........................................................................................................................................16
le 21/05/09
Page : 2 / 17
BDDF
1. Architecture fonctionnelle
1.1.
Prise en compte de la stratégie et du contexte
Afin d’améliorer l’attractivité des automates BNP Paribas, le programme Accueil & Services a décidé
d’étendre le panel des services proposés sur les automates.
Dans ce cadre, l’intérêt d’intégrer des services de paiement sur les automates apparaît aujourd’hui comme
prioritaire et permet, à partir de la création d’une architecture commune, d’ouvrir à terme de nombreux
services dont les marchés sont propices ou en croissance (rechargement GSM, rechargement de cartes pré
payées, rechargement Navigo, rechargement Moneo, paiement de facture…).
BNP Paribas a remporté l’appel d’offre « Orange Pay » le 06 juin 2007. L’objectif de cet appel d’offre est de
produire et d’émettre deux nouvelles cartes bancaires :

La carte Orange Classique Visa sera fournie par CETELEM

La carte pré-payée « JUMP » (ex TEEN’S), 1ère carte de paiement et de retrait
rechargeable (via le prélèvement automatique, le canal Internet et le canal Automate).
La carte «JUMP» (ex TEEN’S) a pour objectif d’enrichir la gamme de cartes BNPP en intégrant la première
carte bancaire prépayée rechargeable pour les jeunes. Cette carte de type co-brandée marque le début d’un
partenariat avec la société Orange. Ce partenariat impliquera la création d’une joint-venture BNP Paribas /
Orange et l’émission d’autres types de cartes (comme la carte classique Orange CETELEM).
La carte JUMP sera tout d’abord émise par la joint-venture BNP Paribas / Orange, créée à la suite à la
contractualisation du partenariat entre les deux sociétés (appel d’offre Orange du 6 Juin 2007 gagné par
BNP Paribas. Elle sera proposée à des adolescents (entre 11 et 17 ans), clients « particuliers » BNPP ou
non. Dans un second temps, la souscription pourra aussi être effectuée dans les points de vente Orange,
sous réserve que les contrôles demandés exigés par la réglementation bancaire soient effectués.
La carte «Jump», de type VISA, respectera les normes Carte Bancaire. Elle permettra des transactions de
retraits ou paiements (y compris e-commerce), domestiques ou internationaux, et sera à autorisation
systématique avec un plafond inférieur à 800 €.
Le projet « rechargement cartes pré-payées sur automate » a un triple objectif :
 La mise en place d’une architecture paiement mutualisable avec l’implémentation de
nouveaux services (rechargement GSM, paiement sur automates, …).
 L’acceptation au retrait d’espèces des deux nouvelles cartes (cartes Orange JUMP et
Orange CETELEM) sur les automates BNP Paribas.
 L’utilisation de l’architecture de paiement pour ouvrir le service de rechargement Carte
« JUMP » sur les automates BNP Paribas :
o
Mettre en place sur le parc automates BNP Paribas le service de rechargement
Cartes Pré payées. Cela s’inscrit dans la logique du programme Accueil & Services
dont l’objectif est d’étendre le panel des services proposés sur les automates.
o
Offrir aux clients la possibilité de pouvoir recharger une carte pré payée Orange
« JUMP » sur les automates BNP Paribas migrés en application unique V2.
o
Proposer le solde du compte sur le ticket après un retrait de porteurs des deux
nouvelles cartes sur un automate BNP Paribas.
le 21/05/09
Page : 3 / 17
BDDF
Solution :
Les évolutions à mettre en œuvre dans le cadre de ce projet sont majoritairement d’ordre technique avec
notamment la mise en place :

D’une application unique à installable sur les automates du parc BNPP proposant le service de
rechargement de cartes pré-payées (Orange JUMP et d’autres dans le futur)

De la gestion du paiement sur automate au niveau des serveurs et frontaux monétiques.

D’une plate-forme de paiement externalisée, connectée aux serveurs et frontaux monétiques, gérant
la base des comptes fictifs rattachés aux cartes Orange JUMP, le routage des autorisations de
paiement émises par les automates bancaires et l’envoi des fichiers de remises aux serveurs de
compensation bancaires.

De statistiques liées à l’activité de retrait et de rechargement des cartes co-brandées (Orange JUMP
et Orange CETELEM) sur les automates affichables sur les outils intranet de suivi du suivi du parc
automate BNP Paribas.

De la compensation des transactions de rechargement pré-payées effectuées sur automate par les
porteurs confrères sur la base des fichiers de remise fournies par la plate-forme EXPERIAN.
Transaction de retrait carte Orange JUMP sur automate :
Le retrait d’espèces effectué sur avec cette carte respectera scrupuleusement la cinématique de la
transaction de retrait d’espèces rapide définie pour l’application NAUSICAA V2. Le ticket client comportera
par contre le solde avant retrait qui sera remonté de la plate-forme de paiement EXPERIAN.
Transaction de rechargement carte Orange JUMP sur automate :
L’application NAUSICAA NCR permet au porteur BNP Paribas ou confrère de sélectionner la fonction
rechargement carte JUMP après la saisie de son code confidentiel. Après la sélection de l’identifiant de la
carte JUMP à recharger (numéro de téléphone sur 10 caractères numériques) et du montant (au minimum
10 euros), le porteur devra re-saisir son code confidentiel afin de respecter la réglementation décrite dans le
manuel de paiement sur automate bancaire (MPAB). La demande d’autorisation est alors envoyé à
destination du serveur monétique et guidée jusqu’à la plate-forme de paiement EXPERIAN qui la traitera.
Que la réponse soit positive ou négative, l’automate imprimera au client un ticket récapitulatif de
confirmation du succès (ou de l’échec) de la transaction et restituera la carte. Un compte-rendu (Ok ou KO)
sera envoyé en parallèle par l’automate qui fera foi au niveau de la plate-forme pour le crédit du compte fictif
de la carte Orange JUMP (si compte-rendu OK).
Traitement de la demande de rechargement par la plate-forme externalisée :
Lorsque la plate-forme recevra la demande de rechargement en provenance de l’automate, celle-ci vérifiera
l’existence de la carte pré-payée et que le plafond du compte fictif associé n’est pas atteint. Si l’identifiant
existe, elle émettra une demande d’autorisation au serveur d’autorisation BNPP qui la traitera (cas porteur
BNPP) ou la transfèrera au serveur d’autorisation confrère (cas porteur non BNPP). L’en-cours du porteur
demandeur est alors crédité du montant du rechargement si l’autorisation est acceptée. Lors de la réception
d’un compte rendu de rechargement réussi, la plate-forme crédite le compte fictif de la carte Orange JUMP
associée du montant demandé, inscrit la transaction dans le fichiers de remises qui seront envoyés au
serveur de compensation BNPP, envoie un sms au porteur de la carte JUMP et au représentant légal du
contrat porteur (pour respecter des questions d’ordre juridique liées au blanchiment d’argent et à la
prostitution sur les mineurs).
IMPORTANT :

Le choix de l’architecture de paiement incluant une plate-forme externalisée a été imposé par Retail compte tenu
des délais très stricts qui nous sont imposés pour le déploiement du service de rechargement de cartes pré-payées
sur les automates bancaires, dans le souci de respecter les engagements contractualisés entre Orange SA et BNP
Paribas. Nous n’avons par conséquent pas pu étudier et chiffrer les investissements liés aux autres solutions
le 21/05/09
Page : 4 / 17
BDDF
d’architecture reposant sur la mise en place d’une plate-forme de paiement interne ou d’un progiciel intégré au
système d’information BNPP
 Le choix du prestataire EXPERIAN pour le développement de la plate-forme externalisée de paiement a
été imposé par la MOA Retail, responsable de l’émission de la carte pré-payée JUMP. Cette plateforme doit en effet également gérer l’informatique de la joint-venture BNP Paribas de paiement (tenue
de la position des comptes des cartes pré-payées).
 Le fournisseur de l’application automate, NRC, est le même que celui choisi dans le cadre du projet
Application Unique (PJ01736) lancé afin d’uniformiser les échanges entre l’automate, les serveurs
monétiques et le canal Web Automate.
 Le fournisseur de l’applicatif du serveur monétique (GDG) et du frontal monétique (SFR) est le même
que celui choisi dans le cadre du projet Application Unique (PJ01736).
1.2.
Processus métier/fonction
La cinématique automate proposée au client pour le rechargement carte pré-payée sera la suivante (voir
page suivante) :
le 21/05/09
Page : 5 / 17
BDDF
Schéma : Principe de rechargement d’une carte pré-payée
Insertion carte
MENU
Etape INI_08
Saisie du code
Fermeture
transaction
EMV
F3 : Retour au menu
Etape Menu Principal
Mention éventuelle
ticket
indisponible
Autres choix
Choix service
Etape EE_TIC_01
Continuer
sans ticket ?
Non
Choix ‘F3 : Rechargement’
F7 : Restitution
carte
Fonctions existantes
non détaillées
Ouverture
transaction
EMV
RC
Ticket
disponible ?
Oui
F4 : Continuer
Menu Rechargement
Bypassé
si 1 choix
Choix fonctions de
rechargement (carte,
GSM,…)
Choix ‘F1 : Rechargement
carte’
Mention éventuelle
ticket
indisponible
F7 : Restitution
carte
RC
Etape
RGT_CPP_MSG1
Ecran d’attente
Timeout /
Non réponse
Emission de
message 1 ‘Demande
d’Information initiale’ /
Attente réponse
PB1
Message 1
1
le 21/05/09
Page : 6 / 17
BDDF
1
3
Bandeau de comm.
Etape RGT_CPP_01
Bandeau de comm.
Etape EE_CPP_01
F7 : Restitution
carte
Saisie identifiant carte à
recharger
Re saisie identifiant carte à
recharger
suite à erreur
F8 : Valider
F7 : Retour
F5 :
Modifier
F8 : Saisie
montant
Etape RGT_CPP_02
F7 : Restitution
carte
RC
Etape RGT_CPP_09
Saisie montant d’après
grille ou demande saisie
explicite
Saisie montant d’après
grille ou demande saisie
explicite
RC
F7 : Restitution
carte
F1 à F6
Montant saisi
Règles
de saisies
non respectées
Etape RGT_CPP_04
Ecran confirmation
récapitulatif du paiement
RC
F7 : Restitution
carte
F8 : Valider
F8 : Valider
Etape RGT_CPP_05
Ecran confirmation
ressaisie code conf.
avant demande
Bandeau de comm.
Etape RGT_CPP_06
Ecran d’attente réception
demande d’auto.
Attente
Réception demande
auto.
Emission de
message 2 : Demande
autorisation de type
Paiement / Attente
réponse
Message 2
Timeout :
réponse message 2
non reçue
PB1
Réponse reçue
2
le 21/05/09
Page : 7 / 17
BDDF
2
Valeur retour
auto ?
Plafond
dépassé
OK
3
Identifiant incorrect
Solde
insuffisant
Service
indisponible
3ème essai
KO de
rechargement
?
PB1
Non
Oui
Etape EE_CPP_03
Etape EE_CPP_02
Etape EE_CPP_ERR01
Etape RGT_CPP_06
'Plafond dépassé'
'Solde insuffisant'
ou
service indisponible
Nombre de saisies
possibles dépassées
Confirmation
Temporisation
Temporisation
Temporisation
Temporisation
Etape RGT_CPP_08 et
9
Etape RGT_CPP_08 et
9
Attente impression
ticket OK
Attente impression
ticket KO
Lancement édition ticket
Edition journal
attente fin éditions
Lancement édition ticket
Edition journal
attente fin éditions
Edition(s) terminée(s)
Edition(s) terminée(s)
Etape RGT_CPP1_KO2
Etape RGT_CPP1_OK2
Ecran d’attente
Ecran d’attente
Emission message 3
CR opération
Emission message 3
CR opération
Message 3
Etape RET_10
Etape RET_10
Restitution carte
Restitution carte
Restitution carte
Restitution carte
Message 3
Carte reprise ou capturée
Etape RET_06
Fin
Carte reprise ou capturée
Remerciements
le 21/05/09
Fin
Page : 8 / 17
1.3.
BDDF
Description du niveau système d’information
1.3.1.
Positionnement dans le plan d’urbanisme
Le projet « Rechargement Cartes Pré Payées » est positionné dans le système d’information de BDDF
(automate, serveurs et frontaux monétiques, serveurs de compensation) et dans le système d’information de
EXPERIAN (plate-forme de rechargement et base compte des cartes pré-payées).
1.3.2.
Positionnement dans le modèle fonctionnel du Métier
Le projet permet d’ouvrir un échange de données de paiement (rechargement cartes pré-payées) entre
l’automate, les serveurs monétiques et la plate-forme de rechargement externalisée. L’automate jouera
désormais le même rôle qu’un terminal de paiement électronique (TPE), c'est-à-dire qu’il collectera les
demandes de rechargement, à la seule différence près que le contrôle du code confidentiel sera toujours
effectué en on-line (envoi systématique d’une demande d’autorisation de type paiement).
La plate-forme sera dans un premier temps responsable de l’envoi des demandes d’autorisation suite à
réception des demandes de rechargement au cours de laquelle elle vérifiera l’existence de l’identifiant de
la carte pré-payée saisi par le client sur l’automate dans la base compte. Dans un deuxième temps, la
plateforme, à réception du compte rendu de retrait envoyé par l’automate pour terminer la transaction de
paiement, devra créditer le solde du compte rattaché à la carte pré-payée avec le montant de la
recharge souhaité.
Toute demande de rechargement donnera lieu à l’émission d’un compte-rendu (positif ou non) qui sera
récupéré sur le serveur monétique et envoyé à des infocentres chargés de générer des statistiques
périodiques sur l’activité de paiement sur automate.
le 21/05/09
Page : 9 / 17
1.3.3.
BDDF
Modèle fonctionnel du projet
Nom du SI concerné :
groupe de
macro-fonction
fonctions
fonction
domaine
fonctionnel
processus
correspondant
(si décrit)
PILOTAGE
Collecter les
informations
Mettre à disposition
l’information
Traitement de
données
SUPPORT
Alimenter fichier de
remises à réception d’un
nouveau compte-rendu de
rechargement
Compensation
Envoi quotidien du
interbancaire
fichier de remises
rechargement vers
compensation
interbancaire
Générations de
Alimentation des
statistiques des
infocentres STAR et MFS
activités retrait et
et génération des
paiement
statistiques par l’outil
Harry Pilote
OPERATIONNEL
Traitement des
Contrôles
Vérification du non
demandes de
dépassement du
rachargement
plafond de paiement du
porteur demandeur de
la recharge et de
l’existence de
l’identifiant de la carte
pré-payée
Comptabilisation
Débit compte du
interne/externe
porteur demandeur du
montant de la recharge.
Acquisition des
remises
Crédit compte de la
carte pré-payée.
Echange client
Nouvelle filière de
paiement
Edition client
ECHANGE
Permettre le rechargement
de cartes pré-payées sur
automate
transmettre un message / Fournir un ticket
objet contractuel
récapitulatif de
l’opération de
rechargement au client
le 21/05/09
Page : 10 / 17
1.3.4.
BDDF
Modèle informationnel du projet
Ex. Personnes Physiques
personne
Compte
év
én
rd
co
ac
Ex.Contrat
Ex. Agence du réseau
em
en
t
pr
o
du
it
e
tur
uc
str
Ex. Carte
Ex. Compte rendu
d’événement
Ex.Compte à vue
Indiquer les grands concepts utilisés par le projet et préciser ce que chaque concept recouvre
pour le projet.
1.4.
Description de l’architecture fonctionnelle
1.4.1.
Description de l’architecture
Les concepts manipulés pour le Système d’information BDDF s’articulent de la manière suivante :
Les Personnes (Porteurs) sont utilisatrices de Produit (Cartes de retrait).
A chaque Carte est associé au moins un Compte (Compte principal rattaché à la carte).
Les Porteurs ont un Accord (Contrat porteur) pour consulter (ou non) le Compte principal rattaché à la carte.
Lors d’un rechargement de carte pré-payée effectué sur un automate, le non dépassement du plafond de
paiement associé au compte principal rattaché à la carte du porteur demandeur (qui peut être un porteur
BNPP ou Confrère) ainsi que le débit du montant de la transaction de rechargement sur ce compte est
vérifié. Cette vérification utilise les concepts Personne, Produit, Compte et Accord.
La vérification de l’identifiant de la carte pré-payée saisi sur l’automate ainsi que le crédit du montant de la
transaction de rechargement sur le compte unique rattaché n’impliquent pas les concepts Personne, Produit,
Compte et Accord car la base compte gérant la carte n’est pas intégrée au Système d’Information BDDF.
 Evènements :
 Evènement déclencheur :
o Rechargement effectué sur automate
le 21/05/09
Page : 11 / 17
BDDF
 Evènements déclenchés :
o Compte-rendu de rechargement client (OK/NOK)
o Alerte automate
 Impacts par concept :

Structure :
identifiant agence et identifiant automate.

Personne :
porteur de carte qui a demandé le rechargement de la carte pré-payée

Accord :
contrat carte du porteur demandeur du rechargement pour authentification et accès
au service (porteur BNPP uniquement), la carte pré-payée et les porteurs
demandeurs confrères étant gérés hors du système d’Information BDDF

Compte :
numéro du compte principal rattaché à la carte du porteur demandeur du
rechargement sur automate (dans le cas d’un porteur BNPP uniquement)

Evénement :
compte-rendu de rechargement (réussi ou non) remonté au GDG

Produit :
pas de nouveau produit (les deux cartes pré-payées étant gérées hors Système
d’Information BDDF, mais les cartes BNPP demandeurs d’un rechargement sur
automate seront gérées (vérification des droits au niveau de la carte).
1.4.2.
Schéma synthétique
Plateforme de
rechargement
EXPERIAN
NAUSICAA - LOT V2+
GDG
1 - Demande
d’information initiale
Réponse GDG
SFR
Alimentation
champs
réponse
Msg 0100 (*1)
Réponse autorisation
Msg 0110 (*2)
SAA/SAPRO
Statistiques
CTC/RAC/RFC
(STAR, FMS)
Réseau
eRSB
Réseau
eRSB
Demande d’autorisation (si porteur BNPP) et réponse
Vérification id
carte pré-payée
2 - Demande
d’autorisation
de type paiement
Compensation
Plate-forme
Emission CPP
Demande d’autorisation
Demande d’autorisation (si porteur
non BNPP) et réponse
Réponse autorisation
0400
Edition
TICKET client
0410
0400
0410
3 - Confirmation
du paiement (OK / KO)
Msg 0120 (*3)
- Crédit compte
de la carte
rechargée
- Ajout
dans JDF
Msg 0130
Fourniture ‘extracts’
Fichier quotidien des remises
1 : Demande d’information initiale (DIX)
Réponse / Fourniture contexte de la transaction de paiement :
- horodatage
- numéro du point d’acceptation
- identifiant banque acquéreur
- numéro du contrat acquéreur
3 : Confirmation du paiement OK / KO ( A81)
=> Inscription du CR dans le journal de fonds du GDG
=> Crédit du compte de la carte rechargé
Note : La plateforme EXPERIAN n’annule pas la demande d’autorisation en cas de non-réception de la confirmation de paiement sauf
sur réception d’un message de redressement 0400.
Les extracts GDG incluant l’activité de rechargement alimentent ensuite les infocentres STAR et FMS
2 : Demande d’autorisation de type paiement (A81)
=> Demande d’autorisation sur la carte acquéreur
=> Réponse à la demande (OK/NOK)
Messages GDG / SFR / RSB :
*1: Le message 0100 contient un champ privatif ‘Identification de la carte prépayée à recharger
*2 : Le message 0110 contient un champ (éventuellement) privatif contenant le solde du compte de la carte
prépayée à recharger et un champ contenant le montant maximal pouvant être crédité, au moment de la demande
d’autorisation, sur la carte à recharger (les cartes concernées ont un plafond de solde créditeur maximum)
*3 : Ce message sera réémis par le GDG si le msg d’acquittement EXPERIAN (msg 130) n’est pas reçu. Le nombre maximum de réémission
ainsi que le délai entre deux réémissions sera fixé par un SAF (« Step and Forward ») paramétrable et livrable sous forme de fichier sur le GDG
le 21/05/09
Page : 12 / 17
1.4.3.
BDDF
Description (texte)
L’architecture de paiement à mettre en place met en jeu 4 éléments :
 L’application automate (application unique NCR avec protocole DIEGO V5.2 dans sa version V2+ et
DIEGO V6 dans sa version V3+)
 Le serveur monétique (GDG) et le frontal d’échange avec le réseau eRSB (SFR)
 La plateforme de paiement externalisée
 Les serveurs d’autorisation et de compensation
Lorsque le client sélectionne la fonction de rechargement de cartes pré-payées dans le menu automate,
l’automate émet une demande d’information initiale à destination du GDG pour que celui-ci lui retourne le
contexte de la transaction de paiement. Les champs suivants seront retournés par le GDG :










Horodatage de la transaction
Identifiant acquéreur
Numéro de contrat accepteur
Numéro logique du terminal
Numéro de transaction opérateur
Type de site
Type d’activité commerciale
Acquirer identifier
Merchant category code
Merchant identifiant
Une fois ces informations collectées par l’automate, le client saisit le numéro de la carte pré-payée à
recharger ainsi que le montant à créditer sur le compte de la carte. Une demande d’autorisation de type
paiement est alors envoyé au GDG avec ces éléments et le contexte. Cette demande est transmise à la
plate-forme externalisée de paiement par le SFR via le réseau eRSB. La plate-forme vérifiera alors
l’existence de l’identifiant de la carte pré-payée saisi dans la base compte et enverra alors une demande
d’autorisation de débit au serveur d’autorisation de la banque émettrice de la carte du client effectuant le
rechargement.
En fonction de ces deux contrôles, la plate-forme répondra à l’automate positivement ou négativement à sa
demande. Dans le cas d’une réponse positive, l’en-cours au débit de la carte sera valorisé du montant du
rechargement (référentiel MCF s’il s’agit d’un porteur BNPP) et l’automate éditera alors un ticket au client et
terminera la transaction en envoyant un message de confirmation du succès de celle-ci. Ce message,
faisant office de compte-rendu, sera dès lors inscrit dans le Journal de Fond (JDF) et dans les extracts GDG
pour alimenter les statistiques liées à l’activité de rechargement sur automate. Ce n’est qu’à réception de ce
flux (toujours via le réseau eRSB) que la plate-forme créditera avec le montant de la transaction le compte
rattaché à l’identifiant de la carte pré-payée correspondant dans la base compte.
le 21/05/09
Page : 13 / 17
BDDF
2. Architecture technique et services
2.1.
Description de l’architecture technique
Le projet s’appuie sur l’architecture du projet PJ01736 « Application Unique » (application automate) sans
utilisation du « Canal Automate » :

Des connexions seront mises en place vers une plate-forme de paiement externalisée via le frontal
réseau SFR en utilisant son interface actuelle avec le réseau eRSB pour gérer les transactions de
retrait de porteurs confrères.
le 21/05/09
Page : 14 / 17
BDDF

Traitement de la demande d’autorisation effectué par la plate-forme externalisée par routage des
demandes de rechargements générées par l’automate sur le réseau eSRB via l’interface du SFR :
vérification de l’existence de l’identifiant carte pré-payée saisi, envoi de la demande d’autorisation
formaté au SAA BNPP pour la compensation, routage de celle-ci au SAPRO (porteur interne) ou au
réseau eRSB (porteur confrère).

Envoi d’un compte-rendu par l’automate à destination de la plate-forme (via le réseau eRSB) pour
terminer la transaction sur l’automate (impression du ticket dans la mesure du possible).
Activation et désactivation du service sur l’automate :
Le service rechargement cartes pré-payées sera activable et désactivable par sécurité au niveau du serveur
monétique GDG (activation/désactivation globale) et automate par automate (maîtrise de la montée en
charge) :

Pour l’application automate NAUSICAA V2+ : via deux nouvelles configurations automates
référencées dans MEOGAB V1 (application fonctionnelle du patrimoine CAN09 / OSPA) dans sa
version V1.

Pour l’application automate NAUSICAA V3+ : via un bit de pilotage dont la valeur (activation ou non)
ème
sera spécifiée dans le référentiel des automates MEOGAB V2 (19
bit de la bitmap des opérations
autorisées de longueur 64 bits).
Périmètre de déploiement du service :
La fonctionnalité devra être disponible au départ sur l’ensemble des automates de retrait (avec le
déploiement et l’activation de la version NAUSICAA V2+). Dans un second temps, l’ensemble des
automates de dépôts se verra recevoir le service de rechargement cartes pré-payées (avec le déploiement
et l’activation de la version NAUSICAA V3+/Orange Pay qui aura intégrée les évolutions applicatives liées au
paiement). Cette version NAUSICAA servira aussi en dernier lieu à mettre à niveau le parc automate de
retrait en NAUSICAA V2+. Au bout du compte, seul le modèle d’automates ILS (Imprimante Libre Service)
ne proposera pas ce service.
Connexion entre la plate-forme externalisée de paiement et le frontal monétique BNPP (SFR) :
Compte tenu des délais serrés pour mettre en place le service de rechargement des cartes pré-payées sur
les automates et de la facture d’émission au réseau e-rsb qui ne sera pas très importante au vu de la
volumétrie annoncée, il a été décidé de ne pas mettre en place de ligne spécialisée sécurisée entre le frontal
monétique (SFR) et la plate-forme externalisée de paiement et d’utiliser le réseau e-rsb pour transmettre les
demandes de rechargement et les comptes rendus de rechargement à la plate-forme. Cette solution permet
de profiter, sans aucune évolution applicative et d’infrastructure lourde, des garanties d’intégrité et de
confidentialité des données clientes du porteur demandeur (numéro du porteur, solde) et du porteur de la
carte pré-payée (identifiant) échangées avec la plate-forme, ainsi que les garanties de qualité de service
fournies par ce réseau interbancaire.
Deux lignes sécurisées devront être mises en place en parallèle entre la bulle monétique et le SI
EXPERIAN afin de répondre aux besoins liés à l’ouverture future d’autres services de rechargement
tel que le rechargement GSM (pour la remontée des catalogues des offres et produits proposées par
les opérateurs de téléphonie. Ces deux lignes devront garantir la redondance du service (au moins
une ligne doit être opérationnelle, l’une doit prendre le relais de l’autre en cas de perte de
connexion).
Connexion entre la plate-forme et les serveurs d’autorisation et de compensation BNPP
Des liens existent déjà entre le SI EXPERIAN et les serveurs d’autorisation BNPP (SAA) et de compensation
(CTC) pour d’autres traitements bancaires.
le 21/05/09
Page : 15 / 17
BDDF
Suivi de l’activité de rechargement des cartes pré-payées sur automate :
Aucune infrastructure particulière n’est nécessaire en terme de serveur et réseau pour le suivi de l’activité de
rechargement. Des évolutions au niveau de l’application et des référentiels existants de statistiques (Harry
Pilot, STAR et FMS) permettront de traiter les comptes rendus des rechargement effectués sur automate
remontés dans les extracts GDG afin d’afficher le niveau de statistiques adéquat pour mesurer de la fiabilité,
de la rentabilité et de l’activité du service : nombre et montant cumulé des transactions réussies et échouées
(par motif)
2.2.
Flux
2.2.1.
N°
Liste des Flux
De
(Serveur / Station)
Zone
01 Automate Bancaire
02 Serveur GDG
03 Frontal SFR
04 Plateforme
Vers
(Serveur / Station)
Zone
Serveur GDG
Frontal SFR
Plate-forme
EXPERIAN
CTC BNPP
Protocole
Protocole GAB Diego
Protocole interne
Protocole STUR 4.01
Protocole « CB2A
Fichier »
Nature du flux
(Applicatif /
Admin. fonctionnelle)
Applicatif
Applicatif
Applicatif
Applicatif
2.2.2.
Schéma de cinématique des Flux
Cf. §1.5 description de l’architecture fonctionnelle.
le 21/05/09
Page : 16 / 17
BDDF
le 21/05/09
Page : 17 / 17

Rechargement cartes pré-payées

Transcription

Documents pareils

Recharger son mobile - Banque Populaire du Sud

Pour télécharger le bon de commande cliquez ICI

Tourmaline Noire - perlesunpeintpeint.fr

DH.be - La Dernière Heure / Les Sports

Aspirateur robot eClean EC-01

Borne de rechargement autonome nomade

wearshield 15crmn - Lincoln Electric

ED 1 MVC simple On veut programmer le jeu suivant : ⁃ Le serveur

la carte - SFR Réunion