Izvješće o korištenju AI API API je programski način za odgovor na jednostavno, ali poslovno kritično pitanje: odakle dolazi naša upotreba i potrošnja AI?

Za mali prototip, nadzorna ploča pružatelja usluga može biti dovoljna. Jednom kada aplikacija opslužuje stvarne korisnike, koristi višestruke ključeve API, poziva više od jednog modela, struji odgovore, pokreće skupne poslove ili preprodaje AI pristup korisnicima, ukupni iznosi na nadzornoj ploči prestaju biti dovoljni. Razvojni programeri trebaju znati koji je ključ, projekt, model, korisnik, stanar, kupac, radno opterećenje ili alat stvorio upotrebu. Financijski timovi trebaju izvješća koja se usklađuju s fakturama dobavljača. Timovi za proizvode trebaju poglede na korištenje usmjerene prema korisnicima. Operaterima su potrebna upozorenja prije nego što se proračun potroši.

To je uloga AI API izvješća o korištenju API. Izlaže podatke o upotrebi i troškovima u obliku u kojem softver može postavljati upite, agregirati, izvoziti, revidirati i provoditi. Dobro izvješće o korištenju LLM-a API čini više od brojanja tokena. Bilježi pružatelja usluga, model, krajnju točku, status zahtjeva, upotrebu predmemorije, troškove hostiranog alata, jedinice za generiranje medija, poravnanje strujanja, stanje asinkronog posla, valutu, verziju cijene i polja atribucije koja povezuju upotrebu s osobama ili sustavima koji su za to odgovorni.

Što bi AI API izvješće o korištenju API trebalo raditi

Minimalno, izvješće o korištenju API vraća AI API aktivnost u vremenskom rasponu. Većina timova treba filtere kao što su vrijeme početka, vrijeme završetka, model, ključ API, projekt, radni prostor, krajnja točka, status i korisnik. Također im je potrebno grupiranje prema korisnim dimenzijama: dan, sat, model, pružatelj, ključ, korisnik, tim, okruženje ili stanar.

Postoje dvije povezane, ali različite površine za izvješćivanje. Korištenje API izvještava o neobrađenim jedinicama upotrebe, kao što su ulazni tokeni, izlazni tokeni, predmemorirani ulazni tokeni, generiranje slika, audio minute, pozivi pretraživanja, vektorska pohrana, brojevi zahtjeva i grupne stavke. AI API izvješćivanje o troškovima API izvještava o novcu: procijenjeni trošak, podmireni trošak, fakturirani trošak, krediti, popusti, marže, valuta i razdoblje naplate. Razvijeni sustavi otkrivaju oboje jer je troškove bez upotrebe teško revidirati, dok upotreba bez troškova ne odgovara na pitanja proračuna.

API također treba podržavati dvije razine detalja. Skupna izvješća odgovaraju na pitanja kao što su ukupni troškovi po danu i modelu. Izvješća na razini zahtjeva odgovaraju koji je točno poziv uzrokovao skok, koji je korisnik upotrijebio ključ, je li stream dovršen ili zašto korisnik osporava naplatu. Agregati su učinkoviti za nadzorne ploče i sažetke naplate; povijest zahtjeva ključna je za reviziju i podršku.

Zašto nadzorne ploče i fakture nisu dovoljni

Nadzorne ploče pružatelja usluga su korisne, ali nisu isto što i trajno izvješćivanje API. Nadzorne ploče mogu se ažurirati s odgodom, prikazivati ​​korištenje u UTC-u, koristiti granice segmenta specifične za pružatelja usluga, odvojiti intervale korištenja od intervala naplate ili izostaviti identifikatore na razini aplikacije koji su važni za vaš proizvod. Osmišljeni su za pregled, a ne za automatiziranu naplatu klijentima, provedbu potrošnje ili tijekove rada za usklađivanje.

Fakture su mjerodavne za plaćanje, ali stižu prekasno za operativnu kontrolu. Dok se faktura zatvori, korištenje je već izvršeno. Fakture također obično sažimaju stavke retka na razini koja je korisna za računovodstvo, ali ne nužno i za otklanjanje pogrešaka. Možda vam neće reći koji je ponovni pokušaj, zamjena, korisnik, API ključ ili radno opterećenje dovelo do određenog troška.

Pojedinačni API odgovori ponekad mogu uključivati ​​podatke o upotrebi odmah nakon poziva modela. To pomaže u računovodstvu gotovo u stvarnom vremenu, ali nije potpuni sustav izvješćivanja. Streaming odgovori mogu vratiti korištenje samo na kraju, ako uopće. Asinkroni i skupni poslovi mogu se riješiti kasnije. Neki davatelji izlažu zasebne administratorske API-je za troškove, dok drugi troše preko tablica naplate u oblaku ili analitike nadzorne ploče.Izvješćivanje API mora spojiti ove signale u konzistentan model.

Osnovni model podataka: knjiga korištenja na razini zahtjeva

Najpouzdaniji dizajn počinje s knjigom na razini zahtjeva. Ovo je trajan interni zapis svake operacije umjetne inteligencije i svakog pokušaja pružatelja koji stoji iza toga. Trebao bi biti pogodan za dodavanje, postavljati upite i eksplicitno o tome je li trošak procijenjen, podmiren ili fakturiran.

Praktični zapis glavne knjige uključuje:

  • ID zahtjeva i, ako je dostupan, ID zahtjeva davatelja usluga.
  • Račun, organizacija, tim, projekt, radni prostor, API ključ, kupac, stanar, krajnji korisnik, radno opterećenje i identifikatori okruženja.
  • Traženi model ili pseudonim, riješeni model pružatelja usluga, pružatelj, krajnja točka, ruta i razina usluge.
  • Vrijeme početka, vrijeme završetka, latencija odgovora, spremnik agregacije i razdoblje naplate.
  • Status, klasa pogreške, broj ponovnog pokušaja, rezervni lanac, stanje otkazivanja i završetak strujanja stanje.
  • Jedinice upotrebe kao što su ulazni tokeni, izlazni tokeni, čitanja u predmemoriju, upisivanja u predmemoriju, tokeni za rasuđivanje, slikovne jedinice, trajanje zvuka, pozivi pretraživanja datoteka, pozivi pretraživanja weba, pohrana vektora, sesije alata i brojevi serijskih stavki.
  • Verzija kataloga cijena, procijenjeni trošak, podmireni trošak, trošak usklađen s fakturom, valuta, krediti, prilagodbe i status usklađivanja.
  • Metapodaci koji štite privatnost kao što su duljina sadržaja, raspršene vrijednosti, kategorija upita ili ID-ovi praćenja, bez potrebe za neobrađenim odzivom i izlaznom pohranom prema zadanim postavkama.

Ova knjiga postaje izvor istine za API odgovore AI potrošnje u stvarnom vremenu. API-ji za korištenje pružatelja usluga i fakture mogu se zatim koristiti za poravnanje, ispravljanje i usklađivanje glavne knjige umjesto da to bude jedino mjesto gdje izvješćivanje počinje.

Važne dimenzije izvješćivanja

Vrijednost izvješća o korištenju API ovisi o atribuciji. Brojevi tokena nisu baš korisni ako se sva upotreba bilježi pod jednim dijeljenim ključem ili jednim generičkim projektom.

Najvažnije dimenzije su obično API ključ, projekt, tim, model, pružatelj, krajnja točka, kupac, stanar, krajnji korisnik, radno opterećenje i okruženje. Za SaaS aplikaciju, atribucija kupaca i zakupaca često je najvažnija. Za internu razvojnu platformu projekt, tim, okruženje i dodjela ključeva mogu biti važniji. Za agenciju ili preprodavača, daljnji klijenti i izvješćivanje o marži postaju centralni.

Izvorne dimenzije pružatelja variraju. Jedan pružatelj može izložiti korištenje API ključem i modelom. Drugi može otkriti naplatu putem projekta u oblaku. Drugi može podržavati ID-ove radnog prostora, geografiju zaključivanja, razinu usluge ili kategorije specifične za alat. Snažan sloj izvješćivanja normalizira uobičajena polja, ali čuva izvorna polja pružatelja usluga za otklanjanje pogrešaka i usklađivanje.

API ključne granice su posebno važne. Ako svaka usluga dijeli jedan ključ, izvješće može prikazati ukupnu potrošnju, ali ne i odgovornost. Izvješćivanje na razini ključa također se prirodno povezuje s kontrolama kao što su LLM API ograničenja potrošnje prema ključu, gdje izvješćivanje daje provjere pragova, upozorenja i čvrsta zaustavljanja.

Jedinice upotrebe šire su od tokena

Mnogi timovi započinju s izvješćivanjem o tokenima i kasnije otkrivaju da to ne objašnjava njihov račun. Moderne AI platforme naplaćuju više od običnih ulaznih i izlaznih tokena.

Trajno AI API izvješćivanje o korištenju API trebalo bi uzeti u obzir predmemorirane ulazne tokene, upisivanje u predmemoriju, čitanje predmemorije, obrazovne tokene, skupne zahtjeve, sesije u stvarnom vremenu, audio ulaz, audio izlaz, generiranje slika, generiranje video zapisa, pretraživanje datoteka, pretraživanje weba, izvršavanje koda, pohranu vektora, uzemljenje, fino podešavanje i hostirani alati specifični za pružatelja usluga.Neke kategorije su jedinice upotrebe, a ne jedinice zahtjeva. Drugi se temelje na vremenu, pohrani ili po operaciji.

Nemojte ih sažeti u jedan stupac tokena. Ukupni tokeni su korisni, ali izvješća o troškovima trebaju izvornu vrstu jedinice. Cijene čitanja predmemorije mogu se razlikovati od cijene novog unosa. Skupni poslovi mogu imati različite stope od sinkronih zahtjeva. Hostirani alati mogu proizvesti troškove čak i kada upotreba tokena izgleda uobičajeno. Ako izvješćivanje API skriva ove razlike, tim za korisničku podršku teško će objasniti račune.

Procijenjeni, podmireni i fakturirani trošak

Izvješćivanje o troškovima treba odvojiti procjene, podmirene iznose i fakturirane iznose. Njihovo miješanje u jedno polje stvara probleme s usklađivanjem.

Procijenjeni trošak izračunava se tijekom ili odmah nakon zahtjeva korištenjem trenutnog kataloga cijena. Korisno je za nadzorne ploče, upozorenja, unaprijed plaćena stanja i provedbu proračuna. Podmireni trošak izračunava se nakon što je poznata konačna upotreba davatelja usluga. Može se razlikovati jer je tok otkazan, asinkroni zadatak dovršen kasnije, pružatelj je vratio konačnu upotrebu nakon odgovora ili je putanja ponovnog pokušaja promijenila stvarne pokušaje pružatelja. Fakturirani trošak usklađen je s izjavama o naplati pružatelja usluga i može uključivati ​​popuste, kredite, poreze, stope za poduzeća, minimalne iznose, povrate ili prilagodbe.

AI API izvješće o troškovima API trebalo bi jasno prikazati stanje troškova. Polja kao što su estimated_cost, settled_cost, invoice_cost, cost_status, settlement_time, invoice_period, valuta, provider_amount, reporting_amount, adjustment_amount i price_version pomažu potrošačima da razumiju koji broj gledaju.

Koristite točno decimalno rukovanje za novac. Binarna aritmetika s pomičnim zarezom slabo odgovara fakturama i saldima kupaca. Pohranite šifre valute, decimalne vrijednosti i izvorne iznose dobavljača odvojeno od konvertiranih iznosa u izvješćima.

Verzija kataloga cijena

Povijesna izvješća ne bi se trebala mijenjati samo zato što se cijena modela danas promijenila. Svaki zapis o upotrebi trebao bi znati koja je verzija cijene primijenjena u trenutku zahtjeva. Ovo je važno za cijene modela pružatelja usluga, stope predmemorije, skupne popuste, cijene hostiranih alata, marže za partnere, popuste specifične za klijente i dogovorene stope.

Katalog cijena treba uključivati ​​efektivna početna i završna vremena, nazive jedinica, valutu, pružatelja usluga, model, krajnju točku, razinu usluge, kategoriju predmemorije, skupni način rada i sva pravila marže ili popusta. Glavna knjiga treba pohraniti verziju razriješene cijene ili dovoljno konteksta cijene za kasniju reprodukciju izračuna.

Bez verzije cijena, usklađivanje na kraju mjeseca postaje nagađanje. Izvješće generirano danas za prošli mjesec možda se više ne podudara s fakturom ili iznosom na koji se suočava kupac koji je prikazan kada je došlo do upotrebe.

Streaming, ponovni pokušaji, rezervni i asinkroni poslovi

LLM izvješćivanje je teže od običnog API mjerenja jer životni ciklus zahtjeva nije uvijek čist zahtjev-odgovor događaj.

Za strujanje, API bi trebao zabilježiti kada je tok započeo, je li klijent prekinuo vezu, je li pružatelj vratio konačnu upotrebu, koliko je izlaznih tokena emitirano i je li trošak konačan. Otkazani streamovi mogu stvoriti sporove ako aplikacija prikazuje djelomičan odgovor, ali knjiga ne bilježi upotrebu, ili ako naplata davatelja uključuje generirani izlaz koji korisnik nikada nije primio.

Ponovni pokušaji i rezervni zahtjevi zahtijevaju pažljivo modeliranje. Ako zahtjev prvo pozove jednog pružatelja, ne uspije nakon djelomičnog rada, zatim se vrati na drugi model, knjiga bi trebala zabilježiti svaki pokušaj pružatelja. Podmireni trošak koji se odnosi na kupca može naplatiti samo uspješan pokušaj, sve pokušaje ili iznos specifičan za policu.Izvješćivanje API trebalo bi omogućiti reviziju i internih troškova dobavljača i vanjske politike naplate.

Asinkronizirani i skupni poslovi trebaju stanja životnog ciklusa: na čekanju, u tijeku, dovršeno, neuspjelo, poništeno, djelomično dovršeno i poravnato. Tamo gdje pružatelji vraćaju korištenje na razini stavke, izvješćivanje API treba sačuvati poravnanje na razini stavke tako da jedna neuspješna stavka ne poremeti cijeli posao.

Zbirni podaci, analiza, izvozi i paginacija

Izvješćivanje API obično treba nekoliko obrazaca pristupa.

Krajnje točke združivanja trebaju podržavati vremenske prozore, širine spremnika, filtri i grupiranje po dimenzijama. Uobičajeni primjeri uključuju cijenu po danu i modelu, tokene po ključu i krajnjoj točki, zahtjeve po statusu i pružatelju ili potrošnju korisnika po mjesecima. Kratke kante pomažu u operacijama i otkrivanju anomalija. Dnevni i mjesečni skupovi pomažu u financijama, naplati i analizi proizvoda.

Krajnje točke detaljne analize trebale bi dohvatiti povijest zahtjeva s determinističkim redoslijedom i paginacijom kursora. Skupovi podataka o upotrebi brzo postaju veliki, pa pomaknuta paginacija može postati spora ili nedosljedna. Stabilni pokazivači, vremenski ograničeni filtri i nepromjenjivi ID-ovi zahtjeva čine izvoz sigurnijim.

Krajnje točke izvoza trebale bi podržavati CSV, JSON i sheme prilagođene skladištu. Veći izvozi trebali bi se izvoditi kao idempotentni poslovi koji se mogu ponovno pokušati bez duplih redaka ili preskočenih stranica. Financijski i FinOps timovi možda žele tablice troškova i upotrebe inspirirane FOCUS-om za dodjelu, nadzor i optimizaciju, ali jedinice specifične za AI kao što su čitanja predmemorije, pozivi alata i generirani mediji često trebaju dodatne stupce.

Za ljudski pregled, API-ji za izvješćivanje često pokreću AI API nadzornu ploču za analizu upotrebe. API i nadzorna ploča trebaju se slagati oko definicija, ali API treba ostati upotrebljiv bez nadzorne ploče.

Usklađivanje između pružatelja usluga i faktura

Usklađivanje je proces objašnjavanja razlika između glavne knjige aplikacija, API-ja za korištenje pružatelja, faktura pružatelja usluga, evidencije plaćanja, kredita, povrata novca i faktura korisnika. Nije izborno ako je uključen pravi novac.

Korisni model usklađivanja pohranjuje razdoblje fakture davatelja usluge, referencu retka fakture davatelja usluga, početak i kraj obračunskog razdoblja, vremensku oznaku namire, razlog prilagodbe, iznos povrata, iznos kredita i status usklađivanja. Također bi trebao sačuvati izvorne jedinice i identifikatore pružatelja tako da inženjer podrške može pratiti prijavljeni ukupni iznos do izvornih podataka pružatelja usluga.

Očekujte razlike. Nadzorne ploče pružatelja mogu se ažurirati kasnije od zapisa zahtjeva. Obračunska razdoblja možda neće odgovarati lokalnim razdobljima korisnika. Neki davatelji javljaju u UTC-u. Tablice naplate u oblaku mogu uključivati ​​poreze, kredite ili agregaciju na razini projekta. Prilagođeni ugovori o cijenama možda neće biti vidljivi u odgovorima vremena izvođenja. Dobro izvješćivanje API ne pretvara se da te razlike ne postoje; daje timovima polja za objašnjenje.

Privatnost i zadržavanje

Izvješćivanje o korištenju ne bi trebalo zahtijevati pohranjivanje neobrađenih upita ili izlaza modela prema zadanim postavkama. Na većinu pitanja o troškovima i atribuciji može se odgovoriti metapodacima: ID-ovi zahtjeva, ID-ovi ključeva, ID-ovi korisnika, nazivi modela, brojevi tokena, korištenje alata, vremenske oznake, status i polja s troškovima.

Postoje slučajevi u kojima snimanje sadržaja pomaže u otklanjanju pogrešaka, pregledu zlouporabe ili podršci. Ako se sadržaj pohranjuje, treba ga kontrolirati eksplicitnom politikom, kontrolom pristupa, ograničenjima zadržavanja i pravilima redakcije. Bilježenje samo metapodataka sigurnija je zadana za mnoge sustave za izvješćivanje o upotrebi LLM-a.

Zadržavanje treba dokumentirati. Uobičajeni obrazac je zadržavanje detaljne povijesti zahtjeva kraće razdoblje, a agregiranih sažetaka dulje. Izvješća o naplati upućena korisniku možda će morati ostati dostupna tijekom trajanja fakture ili ugovora.Interni tragovi otklanjanja pogrešaka mogu imati puno kraće razdoblje zadržavanja.

Kontrola pristupa i ograničenja zakupca

API-ji za izvješćivanje mogu otkriti osjetljive poslovne informacije. Oni pokazuju tko koristi umjetnu inteligenciju, koliko troši, koje modele poziva, koji su klijenti aktivni i koja radna opterećenja rastu.

Kontrola pristupa treba odgovarati modelu proizvoda. Pojedinačni programeri mogu vidjeti samo svoje ključeve. Administratori tima mogu vidjeti sve projekte u radnom prostoru. Korisnici financija mogu vidjeti trošak, ali ne i tražiti sadržaj. Partneri i preprodavači mogu trebati izvješća s opsegom korisnika bez uvida u nepovezane zakupce. Računi usluga trebali bi imati uske opsege za izvoze i automatizaciju.

Za timove koji grade usluge na vrhu pristupnika umjetne inteligencije, izvješćivanje se često povezuje s Partner API automatizacijom: pružanje usluga klijentima, stanja po klijentima, izvješća o korištenju nizvodno, povratni pozivi i naplata prodavača. U tom okruženju, izolacija stanara dio je dizajna izvješćivanja, a ne naknadna misao.

Gdje se pristupnik uklapa

Pristupnik s više modela mijenja arhitekturu izvješćivanja. Umjesto naknadnog povezivanja zasebnih izvješća OpenAI, Anthropic, Gemini i drugih davatelja usluga, pristupnik može bilježiti normaliziranu upotrebu dok promet prolazi kroz njega. To olakšava implementaciju dodjele na razini ključa, analitike više pružatelja usluga, ograničenja potrošnje, povijesti zahtjeva i izvješćivanja korisnika.

Izvješćivanje na razini pristupnika nije automatski mjerodavno za konačne fakture pružatelja usluga. Još uvijek treba usklađivanje, porijeklo specifično za pružatelja usluga i kontrolu verzije cijena. Ali ima veliku prednost: može uhvatiti kontekst na razini aplikacije u trenutku zahtjeva. Može znati ID korisnika, tim, API ključ, rutu, zatraženi pseudonim modela, riješeni model davatelja, zamjenski put, stanje povratnog poziva i utjecaj stanja prije nego što postoje podaci fakture davatelja.

Za Model Gate konkretno, relevantne mogućnosti su objedinjena naplata, API-ključno upravljanje, analitika korištenja, timske kontrole, povijest zahtjeva, transakcije, Telegram integracije, povratni pozivi, krajnje točke ravnoteže i automatizacija partnera API u više modela.Praktična vrijednost nije samo ljepši izvještaj; to je dosljedan kontrolni sloj za dodjelu, ograničenja, usklađivanje i naplatu prema dolje.

Kontrolni popis implementacije

Prilikom dizajniranja ili ocjenjivanja AI API izvješća o korištenju API, koristite ovaj kontrolni popis:

  • Definirajte izvor istine za korištenje u stvarnom vremenu, dogovoreno korištenje i trošak usklađen s fakturom.
  • Zabilježite retke glavne knjige na razini zahtjeva prije oslanjanja na agregate.
  • Pohranite zatraženi pseudonim modela i razriješeni model/verziju davatelja.
  • Držite neobrađene jedinice upotrebe odvojeno od novčanog troška.
  • Praćenje predmemorije, alata, medija, pohrane, serije, i eksplicitno jedinice u stvarnom vremenu.
  • Pohranite procijenjene, podmirene i fakturirane iznose u zasebnim poljima.
  • Katalozi cijena verzija i priložite verzije cijena zapisima o korištenju.
  • Predstavlja strujanje, otkazivanje, ponovni pokušaj, zamjensko, asinkrono i grupna stanja.
  • Koristite točno rukovanje decimalnim brojevima za novac i očuvanje kodova valuta.
  • Podržava grupno izvješćivanje, analizu zahtjeva, izvoze i stabilnu paginaciju pokazivača.
  • Očuvajte izvorna polja davatelja potrebna za reviziju i usklađivanje.
  • Primijenite kontrolu pristupa svjesnu stanara na svako izvješće i izvoz.
  • Dokumentirajte kašnjenje izvješća, vremenske zone, granice spremnika i zadržavanje.
  • Pružite kuke upozorenja ili povratne pozive kada izvješćuje o provedbi proračuna.

Uobičajene pogreške

Najčešća pogreška je tretiranje brojeva tokena kao faktura. Tokeni su samo jedan ulaz u cijenu. Predmemorirani tokeni, pozivi alata, generirani mediji, razine usluga, grupne stope, popusti i dogovorene cijene mogu promijeniti račun.

Još jedan uobičajeni kvar je gubitak atribucije. Ako više aplikacija, korisnika ili okruženja dijeli isti ključ, izvješćivanje API ne može kasnije rekonstruirati odgovornost. Širite identifikatore kupaca, zakupaca, korisnika, radnog opterećenja i okoline u trenutku zahtjeva.

Timovi također prerano miješaju procijenjene i konačne troškove. Zbog toga nadzorne ploče možda izgledaju jednostavno, ali otežava korisničku podršku i usklađivanje. Neka stanja troškova budu vidljiva.

Pretjerana normalizacija je još jedan rizik. Objedinjena shema je korisna, ali važna su polja specifična za pružatelja usluga. Ako sustav odbaci regiju zaključivanja, razinu usluge, kategoriju predmemorije, vrstu hostiranog alata, skupni način rada ili ID zahtjeva davatelja, možda će kasnije biti nemoguće objasniti razliku u naplati.

Na kraju, izbjegavajte pohranjivanje neobrađenih upita kao zadanog odgovora na vidljivost. Metapodaci koji štite privatnost obično odgovaraju na pitanja izvješćivanja s manje rizika.

Zaključak koji se može poduzeti

Izvješće o korištenju umjetne inteligencije API API trebalo bi programerima, operaterima, financijskim timovima i vlasnicima proizvoda dati zajednički, programski pogled na potrošnju umjetne inteligencije. Trajni dizajn je knjiga na razini zahtjeva s jasnom atribucijom, neobrađenim jedinicama upotrebe, odvojenim stanjima troškova, verzijama cijena, porijeklom pružatelja, poljima usklađivanja i zadržavanjem koji vodi računa o privatnosti.

Za prototip jednog pružatelja, nadzorne ploče pružatelja i administratorski API-ji mogu biti dovoljni. Za proizvodne sustave, proizvode okrenute kupcima, aplikacije s više modela ili tijekove rada prodavača, izvješćivanje mora postati dio arhitekture aplikacije.Pristupnik kao što je Model Gate može pružiti kontrolnu točku na kojoj se susreću API ključevi, analitika upotrebe, transakcije, dopuštenja tima, objedinjena naplata i radni tokovi partnera API, dok još uvijek čuva pojedinosti pružatelja potrebne za usklađivanje konačnog računa.