Bankovní API - Jaký je ideál?

#8

Petr Dvořák

CEO at Lime

E-mail: petr@lime-company.eu

Twitter: @joshis_tweets

Sdílejte přátelům a známým

Otázky lze klást v Q&A boxu

Odkaz na Slideshare v popisu videa

Záznam bude dostupný on-line

Výsledky dotazníku ve formátu CSV

https://dl.dropboxusercontent.com/u/6405782/Bankovn%C3%AD%20API%20-%20vysledky%20dotazniku.csv

Demografické údaje

23

100 %

Muži Ženy

4 %9 %

83 %

4 %

19-26 let 27-35 let 36-45 let 45-55 let

Technologie

Jaké aplikace vyvíjíte?

0 4 8 12 16

2

10

14

15

Webové aplikace Mobilní aplikace Interní systémy a APIDesktopové aplikace Jiné

V jakých programovacích jazycích pracujete?

0 2,5 5 7,5 10

1

3

4

4

6

6

9

9

9

10

Java Objective-C PHP JavaScript Swift C# RubyC++ Python Kotlin

Funkčnosti API

Jaké funkčnosti byste nejvíce ocenili?

0 5,5 11 16,5 22

2

4

5

5

6

10

14

21

21

Přístup k účtům a zůstatkůmPřístup k transakční historiiMožnost založit novou platbuPřístup k nezabezpečeným informacím bankyPřístup k jiným funkcím produktů (inkasa, trv. platby, ...)Skóring klientaAkviziční proces a založení klientaPřístup k ostatním bankovním produktům (karty, investice, úvěry, ...)Přístup k informacích o produktech banky (poplatky, úroky, výhody, ...)

Technikálie API

Jaký přenosový formát by mělo API podporovat?

4 %9 %

87 %

JSON Jiné - Protocol Buffers XML i JSON XML

Jak by mělo být řešené stránkování seznamů?

18 %

41 %

41 %

since, itemCount itemOffset, itemCountpageIndex, pageItemCount

Jak byste řešili řazení a filtrování dat

• Datum od - do. Zbytek si zvládnu profiltrovat na klientovi lokálně. • Filtrovani podle data je dostatecne, zbytek jde resit lokalne. • Používat obecný dotazovací jazyk. • Obecny dotazovaci jazyk. • Facebook relay. • Jednoduché filtry by měly v 95% stacit. • Obecný dotazovací jazyk. Něco, co je odvozeno třeba z SQL nebo něčeho jinéhom

standardního. • Obecný dotazovaci jazyk. • castka, mena, datum. • Atributy: cas, castka, +/-, c.uctu odkud/kam, obsah zpravy, obecny dotazovaci jazyk,

pro snadne rozsireni, kombinace kriterii povazuji za nezbytnou. • Account number, VS. • Numericky od-do, textovy regexpovym hledanim. • Základní parametry preddefinovany, pro ostatní a kombinace nějaka notace pro možnost

and/or složitějších kombinací které aplikace na základě své chytristiky může použít. Zároveň možnost si transakce tagovat s hodnotou a filtrovat na základě těchto metadat

• Adresát/příjemce, typ platby, kategorie ... určitě by bylo vhodné mít možnost filtrovat dle více kritérií (ale není to nutné do verze 0.x)

• Není potřeba řadit, typicky je chci zobrazovat od nejnovější po nejstarší. • Opet razeni podle data staci. • Částky, Typ transakce • Seznam atributu vcetne asc,des • Facebook relay • Jeden atribut by měl v 95% stacit • Obecné řazení může být přímo součástí dotazovacího jazyka (viz SQL). • Jeden atribut staci • id, datum "zapocteni" • Castky, datumy • Podle času • podle vsech, to by nemel snad bejt problem • Více např datum a hodnota, datum a schvalovatel apod. • Datum, objem a typ transakce (přích, odch, karta, poplatek). Řazení dle adresáta a

dalších parametrů mi nedává smysl.

Služba, kterou chci “obalit”

aplikací

Externí databáze a zdroj

dat

Pohled na bankovní API

Stačí základní řazení a filtry, protože to tak doménově dává typicky smysl.

Potřebuji komplexní dotazování, chci umět hledat komplexní souvislosti.

Jak by měl být realizován proces placení?

• Setup pro data plaťáku, Validate pro ověření dat platby, Create pro zavedení platby do systémů, Commit pro autorizaci platby (např. pomocí TAN).

• Jeden endpoint pro platbu, rozdeleni na urovni bankovniho API nedava smysl, protoze z pohledu UX v aplikaci jsou oba pristupy zamenitelne.

• Najlépe mít kombinaci validačního resource • Kombinace validace na klientovi i serveru. Na klientovi zakladni validace na cisla uctu

(modulo), zapornost cisel apod. • Pokud by se jednalo o REST API, tak by melo zustat stateless • Jeden endpoint je nebezpečný, ale těžko říct, jestli dva kroky něco reálně vylepší. • Jeden endpoint pro zadání platby s možností "dry run". Doplňování je problémem

klientského UI, ne API. • Po jednotlivých fázích • Flow různých produktů může být různé. Některé ocení 1 krokové vyřízení, u jiných bych

ocenil provedení validací, na základě kterých dostanu "zamčený" review. • Posledni varianta tzn kombinace • Jeden formát s rozdělovacím atributem: Validace nebo Submit (validace plus potvrzení) • jeden endpoint staci • Kombinace validacni endpoint a odesilaci, s tim ze validacni udělat cachovatelny aby si

to mohla aplikace urychlit ale mit aktualizovatelne • První varianta - vše na straně poskytovatele, aby vývoj aplikace nad API byl co

nejjednodušší.

Podepsání Zadání

Setup Validace

Proces platby?

Validace Zadání

Bezpečnosti API

Jaký protokol by měl být použit k zabezpečení API?

5 %5 %

89 %

OAuth 2.0 Form-based TAuth

Jak by měly být autorizovány platby?

15 %

15 %

31 %

38 %

V rámci aplikace 3. strany (bez prostředku banky)Kombinace, resp. dle účeluV rámci aplikace banky (IB, MB)V rámci aplikace 3. strany (prostředkem banky)

Nefunkční požadavky

Které nefunkční požadavky byste nejvíce ocenili?

0 4,5 9 13,5 18

0

3

9

10

13

18

18

Důkladnou a detailní dokumentaciMožnost jednoduše testovat na sandboxuMožnost jednoduše testovat na živých datechOpen-source kódKlientská SDKDiskuzní fórumÚčet na sociálních sítích

V jakém jazyce by měly být tvořeny příklady?

19 %

24 %57 %

Nějaký jazyk, který znám Můj programovací jazykNepotřebuji příklady, stačí dokumentace

Děkuji

Petr Dvořák e-mail: petr@lime-company.eu twitter: @zinglyapp

http://zingly.cz/

Otázky? :-)

Petr Dvořák e-mail: petr@lime-company.eu twitter: @zinglyapp

http://zingly.cz/