A.

Categorii de utilizatori

Plătitor - persoana care efectuează plata

Debitor - persoana pentru care se efectuează plata (nu este obligatoriu ca
plătitorul şi debitorul să fie aceeaşi persoană)
Emitent de plată - instituţia care emite cererile de plata
Beneficiar de plată - instituţia care primeşte banii in cont / (Admininistraţia
Financiară)
Administrator sistem - persoană cu drept de administrare a soluţiei informatice
Autoritate care are drepturi de interogare asupra bazelor de date ale sistemului

B. Cerinţe tehnice ale sistemului

1. Să permită operaţii de plată online în următoarele condiţii :
• Să poată comunica în mod securizat cu serverele payment
gateway folosind RSA/SHA1, MD5 şi HMAC
• Să poată genera stringuri compatibile cu soluţiile operatorilor de
plăţi online cu carduri de credit
• Să asigure transmitere de date server-to-server
• Să ofere interfaţare cu orice soluţie de tip shopping-cart dezvoltată
în PHP, ASP.NET, ASP + VBScript, ASP + JS, PERL, ColdFusion,
Java.
• Să poată interfaţa cu sistemele 3DSecure
• Să ofere posibilitatea de a monitoriza tranzacţiile pentru
administratorii operatorului
• Să ofere modulele API (Application Protocol Interface) necesare
pentru interfaţări
2. Sa se interfateze cu Sistemul Electronic National în modul descris în
secţiunea IV, “Descriere flux tranzacţional sistem de plăţi on-line şi
integrare cu Sistemul Electronic Naţional”
3. Sa permită :
- interfaţarea cu sistemele electronice ale emitenţilor de plată
- interfaţarea cu sistemele electronice ale beneficiarilor de plată

3. Sa emită dovezi electronice valabile juridic in Romania, dovezi

semnate cu certificate calificate de semnatură electronică
4. Să ofere o interfaţă web tuturor categoriilor de utilizatori
5. Comunicarea între module şi comunicarea cu utilizatorii sistemului
să se facă într-un mod securizat
6. Să ofere facilităţi de arhivare - atât periodică cât şi la comandă - a
informaţiilor
7. Să fie scalabil, permiţând atât scalarea pe orizontală cât şi cea pe
verticală, fără modificări în cod.
 8. Să suporte un volum de tranzacţii mediu de 4000 de tranzacţii zilnic
şi un volum de vârf de 20 de tranzacţii pe secundă.
9. Să conţină un modul care sa permită interacţiunea cu utilizatorii,
obţinerea de feedback si managementul relaţiei cu plătitorii si beneficiarii.
10. Să fie însoţit de documentaţie pentru toate API-urile de interfaţare
cu sistemele emitenţilor de plată, beneficiarilor de plată şi a soluţiilor de tip
shopping-cart.

C. Cerinte funcţionale

1. Funcţionalităţi accesibile administratorului sistemului

1.1. Autentificare la intrarea în sistem

Întregul sistem trebuie să ofere un mecanism de autentificare şi autorizare

bazat pe roluri (grupuri). Un administrator va putea adăuga, modifica şi şterge
roluri din sistem, şi va putea defini pentru fiecare din aceste roluri o listă de
funcţionalităţi accesibile utilizatorilor. Autentificarea se face prin utilizator şi
parolă. Întregul proces de autentificare în sistem trebuie să se desfăşoare
într-un mod securizat, folosind protocolul SSL.

1.2. Configurare beneficiari

Sistemul trebuie să permită administratorilor să definească o listă de

beneficiari – emitenţi de plată ale căror cereri de plată vor putea fi stinse prin
plăţi efectuate online. Pentru fiecare beneficiar se vor putea introduce
informaţiile considerate relevante de către beneficiar.

1.3. Configurare structură organizatorică pentru fiecare beneficiar

Pentru fiecare emitent de plată definit anterior, este necesar ca un

administrator să poată defini o structură organizatorică. Acest lucru
presupune definirea unei structuri ierarhice, alcătuită din unităţi. Pentru
fiecare unitate, administratorul va specifica informaţiile considerate relevante
de către beneficiar.

1.4. Configurare categorii de plăţi şi informaţii definitorii pentru acestea

Sistemul va trebui să fie capabil să interogheze bazele de date ale

beneficiarului în scopul validării plăţii.

Pentru fiecare categorie de plată este necesară definirea informaţiilor pe care

un plătitor trebuie să le introducă înainte de a efectua o plată pentru
aparţinând categoriei respective. Administratorul trebuie să introducă pentru
fiecare plată informaţiile considerate relevante de catre beneficiar.
 Atunci când un plătitor va alege să efectueze o plată aparţinând unei anumite
categorii, sistemul va trebui să prezinte un formular generat în concordanţă
cu informaţiile solicitate de beneficiar. Ca urmare, în momentul efectuării
plăţii, sistemul va stoca aceste informaţii, ce vor fi folosite la obţinerea
raportului de plăţi pentru beneficiarul respectiv.

1.5. Configurare algoritm de plată

După ce administratorul defineşte structura organizatorică pentru un

beneficiar, este necesară specificarea informaţiilor legate de plată. Mai exact,
este necesar să se specifice unde se plăteşte pentru fiecare unitate sau
subunitate emitentă de plată.

Aceste informaţii se pot introduce pentru fiecare subunitate în parte.

Sistemul nu trebuie să permită efectuarea de plăţi către beneficiari ale căror

date legate de algoritmul de plată nu au fost introduse corespunzător, iar
administratorii sistemului trebuie notificaţi la salvarea datelor de acest lucru.

1.6. Administrare conturi de acces în sistem pentru emitentul de plată

Sistemul va trebui să permită accesul în sistem pentru reprezentaţi ai

emitentului de plată (beneficiarului), cu scopul de a consulta informaţiile
legate de plăţile efectuate online. În acest scop, administratorul sistemului va
defini conturi utilizator pentru aceşti reprezentanţi, care vor avea acces numai
la informaţiile legate de plăţile ale căror beneficiar este instituţia pe care o
reprezintă.

2. Funcţionalităţi accesibile plătitorului

Sistemul va conţine o componentă front-end care va interfaţa cu publicul.

Acestă componentă va trebui să aibă următoarele caracteristici:
• Să fie web-based
• Să permită utilizatorilor să se înregistreze şi să se autentifice în sistem,
dar acest lucru să nu fie o precondiţie la efectuarea de plăţi online.
• Să interfaţeze cu Sistemul Elecronic Naţional, prin trimiterea de
informaţii semnate cu privire la plăţile efectuate şi prin solicitarea de
informaţii privitoare la stadiul tranzacţiilor în care sunt implicate aceste
plăţi.
• Să permită administrarea dinamică a structurii conţinutului (prin
intermediul elementelor de meniu, organizării informaţiei pe secţiuni
etc.)
• Să permită diferenţierea conţinutului public (pagini cu informaţii,
accesibile şi utilizatorilor neînregistraţi) de conţinutul privat (pagini
 accesibile doar utilizatorilor autentificaţi – cum ar fi ecranul de
introducere plată şi lista plăţilor proprii)
• Să asigure o compatibilitate cât mai bună cu motoarele de căutare cele
mai cunoscute (Google, MSN, Yahoo, etc), astfel încât, în cazul unei
căutări pe Internet (prin mijloace specifice: cuvinte cheie, etc.), Portalul
trebuie să se regasească printre primele 10 adrese de pe prima pagină
de Internet deschisă pentru anumite cuvinte cheie ce vor fi stabilite
ulterior.
• Proiectarea portalului, tehnologiile folosite, modulele dezvoltate, să nu
afecteze funcţionalitatea, astfel încât deschiderea paginilor sa se facă
rapid pe diverse browsere: Internet Explorer, Mozila, Firefox, Opera.
(ultimele versiuni), având în vedere că utilizatorii pot dispune de
calculatoare mai mult sau mai puţin performante.
• Operaţiunile de căutare în interiorul site-ului se vor efectua prin
intermediul unui motor de cautare integrat în structura portalului,
actualizat automat la fiecare schimbare de conţinut survenită la nivel
de secţiune, submeniu, etc.
• Să ofere posibilitatea de a cauta în interiorul titlurilor, textelor si a
cuvintelor cheie (în loc de “tag”uri) pentru fiecare pagină din site.
• Să ofere posibilitatea de a sorta si afişa rezultatele dupa un algoritm de
relevantă.
• Să ofere posibilitatea afişării contextului in care apar termenii cheie
căutati.
• Paginile dinamice de content generate de portal se doresc a fi replicate
la nivel fizic pe hard-disk, astfel încât (in eventualitatea nefuncţionării
aplicatiei de portal) conţinutul sa fie totuşi la dispoziţia utilizatorului –
cu excepţia interfeţei de plată.
• Accesul la backendul aplicaţiei de portal va trebui sa aibă opţiunea de
restricţionare la nivel de IP.

2.1. Înregistrare în sistem

Portalul va trebui să ofere o modalitate de înregistrare (creare de cont) pentru

utilizatori. Mecanismul de înregistrare se va folosi de double opt-in pentru
verificarea conturilor nou-create şi va fi protejat la atacuri gen script de
înregistrare folosind CAPTCHA.

2.2. Autentificare la intrarea în sistem

Autentificarea în sistem nu este o precondiţie la efectuarea oricărei operaţii ce

are legătură cu plăţile online dar va permite utilizatorilor să verifice lista de
plăţi efectuate şi descărcarea în orice moment a dovezilor de plată pentru
aceste plăţi.

2.3. Efectuarea de plăţi online

Pentru a efectua o plată, plătitorul va avea acces la o funcţie de plăţi online,
apoi va trebui să aleagă tipul de plată pe care doreşte să o efectueze.
Portalul va trebui să solicite informatiile considerate relevante de către
beneficiar.

Sistemul trebuie să poată solicita verificarea corectitudinii acestor informaţii la

momentul plăţii.

a) informaţii care identifică debitorul (dacă se plăteşte pentru o altă

persoană)
• nume, prenume

b) informaţii solicitate de beneficiar pentru tipul de plată respectiv

Se introduc acele informaţii pe care administratorul le-a configurat ca

fiind necesare şi obligatorii pentru categoria de plăţi aleasă.
Sistemul va trebui să valideze corectitudinea informaţiilor introduse, în
conformitate cu criteriile de validare impuse de administrator.

2.4. Primire dovadă de plată semnată digital din partea sistemului de plăţi

Această confirmare are rolul de a dovedi transferul de bani din contul

plătitorului în cel al beneficiarului. Această dovadă este echivalentul unei
chitanţe emise în urma efectuării unei plăţi, şi se va transmite prin e-mail la
adresa specificată de plătitor.

Dovada emisă de sistem trebuie semnată digital folosind un certificat calificat,

emis de o autoritate recunoscută.

Dovada de plată trebuie să conţină informaţiile considerate relevante de către

beneficiar.

2.5. Acces la lista plăţilor efectuate de utilizatorul respectiv prin sistemul

electronic şi status-ul lor

Un utilizator autentificat va avea la dispoziţie un ecran în care va putea

consulta lista de plăţi efectuate de el până în acel moment.

3. Funcţionalităţi accesibile emitentului de plată

3.1. Înregistrare în sistem

3.2. Autentificare la intrarea în sistem

3.3. Vizualizare listă de plăţi on-line

 Emitentul de plată poate vedea în orice moment situaţia plăţilor efectuate
online, ale căror emitent este.

3.4. Comparaţie între plăţi şi datorii de plată

Se face comparaţia dovezilor de plată existente cu datoriile de plată introduse

in sistem. Rezultatul poate fi :
a) greşală de plată.
• dacă suma plătită este prea mare, se returnează bani in contul de
card şi se notifică plătitorul
• dacă suma plătită este prea mică, se notifică plătitorul şi se
evidenţiază în raportul de clearing (raport de comparaţie)
• dacă datele referitoare la datoria achitată sunt introduse greşit, se
notifică plătitorul că a plătit greşit
b) plată efectuată corect.

3.5. Corecţie erori de plată

a) returnare de bani
b) corecţie manuală a informaţiilor introduse de beneficiar înainte ca
datele să fie salvate în sistem

3.6. Raport datorii stinse prin plată electronică

Sistemul trebuie să ofere un raport referitor la numărul şi valoarea datoriilor

stinse prin intermediul plăţilor electronice, grupat pe perioade de timp şi pe
unităţi ale beneficiarului.

3.7. Raport probleme de plată electronică

Sistemul trebuie să ofere un raport referitor la problemele apărute în cadrul

procesului de plată electronică.

4. Funcţionalităţi cu specific financiar pentru beneficiarul de plată

4.1. Raport lista plăţilor on-line efectuate, pe categorii de plată şi unităţi

beneficiar

4.2. Import lista de plăţi efective

4.3. Raport diferenţe

4.4. Corecţie diferenţe

4.5. Export notificări de plată ale sistemului de plăţi pentru debitori

 4.6. Arhivare istoric de plăţi

D. Descriere flux tranzacţional sistem de plăţi on-line şi

integrare cu Sistemul Electronic Naţional

După furnizarea datelor de identificare cerute de portal si verificarea lor de

către sistem, acesta va efectua plata către beneficiar.

Fiecare plată va reprezenta o tranzacţie financiară unică între contul de card

al debitorului şi Beneficiar.

Tranzacţia va fi semnată cu certificat digital emis de IGCTI şi înregistrată în

Sistemul Electronic Naţional (SEN).

Toate tranzactiile vor avea un timestamp şi un identificator unic care va

certifica data efectuării tranzacţiei şi unicitatea acesteia.

Pentru înregistrarea tranzacţiilor va fi dezvoltat un nou serviciu care va fi

adăugat la SEN. Datele preluate din sistemul de plăţi şi rutate prin SEN vor fi
depuse intr-o bază de date ce va fi accesibilă Beneficiarilor de plăţi.

După ce toate formularele de incasare plăţi au fost introduse de către

Beneficiar se va accesa baza de date ce contine plăţile efectuate pentru a
face o verficare a acelor servicii care au fost plătite sau nu de către Debitor.
Ca urmare a verificării automate a formularelor se vor genera rapoarte ce vor
furniza datele de identificare pentru acei care au plătit sau nu, urmând ca
Beneficiarul să ia măsurile corespunzătoare.

E. Cerinţe

1.Cerinţe funcţionale
Cod Descriere Tip
C Construcţie baze de date pentru sistem obligatorie
F1

C Construcţie modul efectuare plăţi obligatorie

F2

C Construcţie modul de acces securizat incluzând CAPTCHA obligatorie

F3

C Construcţie interfaţă pentru administratori obligatorie

F4
 C Construcţie interfaţă pentru reprezentanţii emitenţilor de plată obligatorie
F5

C Construcţie interfaţă pentru reprezentanţii beneficiarului de obligatorie

F6 plată

C Documentaţie pentru toate API-urile de interfaţare obligatorie

F7

C Integrare cu SEN obligatorie

F8

2. Cerinţe operaţionale
Cod Descriere Tip
COP Comunicaţie cu serverele payment gateway folosind obligatorie
1 RSA/SHA1, MD5, HMAC
COP Generare stringuri compatibile cu soluţiile operatorilor de plăţi obligatorie
2 online cu carduri de credit
COP Asigurare transmitere de date server-to-server obligatorie
3
COP Posibilitate de interfaţare cu orice soluţie de tip shopping-cart obligatorie
4 dezvoltată în PHP, ASP.NET, ASP + VBScript, ASP + JS,
PERL, ColdFusion, Java
COP Suport pentru 3DSecure obligatorie
5
COP Suport monitorizare tranzacţii pentru administratori obligatorie
6

3.Cerinţe proces de implementare

Cod Descriere Tip
CI1 Procedurile de lucru pe care ofertantul le va utiliza în timpul obligatorie
implementării, modul în care îşi va organiza echipa de
implementare (număr de specialişti, sarcina fiecărui membru
al echipei, pregătirea profesională, experienţa şi CV pentru
fiecare membru din echipă)
CI2 Recomandări pentru personalul beneficiar (componenţa obligatorie
necesară, sarcinile membrilor echipei).
CI3 Graficul de execuţie a lucrărilor de implementare, cu punerea obligatorie
în evidenţă a fazelor acestora, a livrabilelor şi a punctelor de
interacţiune cu beneficiarul; costurile de implementare vor
 trebui detaliate pe fiecare etapă şi prezentate într-un sumar
(la finalul ofertei)
CI4 Modul de lucru prin care se asigură respectarea prevederilor obligatorie
de calitate
CI5 Project Management obligatorie
Modul în care proiectul va fi măsurat, monitorizat, contabilizat
şi asigurat pe durata implementării sale;
Modul în care modificările şi problemele vor fi identificate şi
raportate
CI6 Modul în care se definesc criteriile de acceptanţă obligatorie

4. Alte cerinţe
Cod Descriere Tip
AC1 Instruirea utilizatorilor sistemului pentru extensiile realizate Obligatorie
AC2 Garanţie pe o perioadă de 12 luni de la recepţie Obligatorie
AC3 Suport tehnic post-implementare pe o perioadă de 12 luni de Obligatorie
la recepţie, incluzând deplasările on-site.