Preverjanje se izvaja, da se zagotovi, da je mogoče račun in naknadno plačilo pravilno obdelati na strani projekta.

S poenostavljeno integracijo se uporabniški ID in naročilo preverita dvakrat: pri prehodu na plačilni obrazec in pri izbiri plačilnega sredstva.

Projekt potrebuje:

• ID uporabnika ali URL za preverjanje naročila(navedite v tehničnih nastavitvah v osebnem računu);
• Obdelovalec, ki lahko sprejme in prepozna parametre zahteve sistema in se odzove, kot sistem pričakuje.

Če se je preverjanje identifikatorja po izdaji računa končalo z napako, potem račun ne bo izdan, uporabnik pa bo s parametrom preusmerjen na stran z napako pri plačilu return_url_fail ali v tehničnih nastavitvah (če stran ni navedena, se podobna stran uporablja na strani sistema). Na stran z napako pri plačilu z uporabo metode GET parameter se samodejno pošlje err_msg s pomenom "Ta lik ne obstaja.".

Zahtevajte parametre od sistema do projekta

Sistem pošlje zahtevo projektu za URL za preverjanje identifikatorja ali uporabniškega reda, določenega v tehničnih nastavitvah v osebnem računu.

• način prenosa - POST;
• kodiranje - UTF-8.

Parameter	Opis parametrov	Oblika parametrov	Obvezni parameter
Uporabniško ime	Identifikator uporabnika ali naročila (enak vrednosti parametra vzdevek v)	niz (256)	Da
userid_extra	Za izvedbo plačila ali zbiranje statističnih podatkov na strani projekta so potrebne dodatne informacije (enake vrednosti parametra nick_extra )	niz (500)	Ne
ključ	Potrditveni podpis zahteve. Nastane kot razpršitev po algoritmu md5 iz združevanja naslednjih parametrov: vrednost parametra Uporabniško ime, skrivni ključ projekta	md5 (0userid0 skrivnost projekta)	Da
znesek		0	Da
paymentid	Preverjanje zahteve za preverjanje. Sprejema samo nič (znesek = 0)	0	Da
Številka naročila	ID plačila v računovodskem sistemu projekta (enako vrednosti parametra Številka naročila v)	varchar (64)	Ne

Parametri odziva projekta

Projekt bi moral prejeti odgovor na zahtevo sistema.

Za prenos parametrov poizvedbe se uporabljajo naslednja pravila:

• format - XML;
• kodiranje - UTF-8.

Parameter	Opis parametrov	Oblika parametrov	Obvezni parameter
Koda	Zahtevajte odzivno kodo. DA- identifikator obstaja. NE- identifikator ne obstaja	(velike in male črke)	Da
komentar	Dešifriranje kode odziva na zahtevo. Primeri besedila: preverjanje parametra uporabniškega imena ni uspelo; preverjanje parametra orderid ni uspelo; preverjanje parametra ključa ni uspelo	niz (400)	Ne

Primer odgovora na zahtevo za preverjanje ID -ja uporabnika ali naročila

DA

Primer minimalnega upravljalnika sistemskih zahtev pri preverjanju uporabnika ali identifikatorja naročila

// Ustvari odzivno funkcijo sendResponse ($ status, $ message = "") ($ response = ""." \ n "; $ response. =" "." \ n "; $ response. =" ". $ status.""." \ n "; $ response. =" ". $ message.""." \ n "; $ response. =""; die ($ response);) // Preverite, ali ID uporabnika ali naročilo obstaja. checkUser ($ userID) ($ sql =" SELECT login FROM users WHERE usr_id = ".intval ($ userID); $ sql); if (mysql_error ()) (return FALSE;) if (mysql_num_rows ($ query) == 0) (return FALSE;) return TRUE;) $ secretKey = "IT \" S_A_PROJECT_SECRET_WORD "; $ projectHash = md5 ($ _ POST ["znesek"]. $ _ POST ["userid"]. $ _ POST ["paymentid"]. $ secretKey); if ($ projectHash! = $ _POST ["key"]) (sendResponse ("NE", "Potrditveni podpis zahteve je neveljaven.");) if (floatval ($ _ POST ["znesek"]) == 0 && intval ($ _POST ["paymentid"]) == 0) (// Zahteva za preverjanje ID -ja uporabnika ali naročila if (checkUser ($ _ POST ["userid"]))) (sendResponse ("YES", "ID obstaja ");) else (sendResponse (" NO "," ID not found ");))

Splošne informacije

Opis vhodnih parametrov

Vhodni podatki: Dokument XML po shemi WS_ULIPZAPRID_2_311_11_04_02 _01_01.XSD

1. Opis izhodnih parametrov

Izhod: XML dokument po shemi WS_OTVVIPULXSD_2_311_14_04_02_01.XSD

ali

Izhod: Dokument XML v skladu s shemo WS_ULIPOTVID_2_311_09_04_02_01.XSD

Parametri kompleksnega tipa so opisani v Dodatku "Opis splošnih podatkovnih struktur" (v klavzulah 10, 6, 9).

1. Povratne kode

№	Povratna koda	Opis povratne kode	Pogoji nastanka	Komentar
1	01	Zahtevane informacije niso bile najdene.	Zgodi se, če podatkov o pravni osebi ni v Enotnem državnem registru pravnih oseb
2	51	Zahteva sprejeta v obdelavo	Pojavi se, ko je zahteva uspešno obdelana
3	52	Odgovor ni pripravljen	Pojavi se, ko odgovor ni pripravljen za zahtevo, ki je bila uspešno sprejeta v obdelavo	Uporablja se pri podajanju asinhrone zahteve
4	53	Podatkov o pravni osebi / samostojnem podjetniku ni mogoče posredovati v elektronski obliki	Pojavi se, ko na zahtevo v elektronski obliki ni mogoče odgovoriti
5	82	Format-logična napaka pri upravljanju	Pojavi se, ko se dokument (zahteva) ne ujema s shemo xsd	Rezerva, se ne sme uporabiti
6	83	Od tega organa ni zahteve z navedenim ID -jem zahteve in vrsto zahtevanih informacij	Pojavi se v primeru, ko je v zahtevi za pridobitev rezultata izjave izjave pravne osebe naveden napačen (neznan) identifikator zahteve in (ali) zahteva s takim identifikatorjem ni prejeta od tega organa	Uporablja se z asinhrono zahtevo (pri prejemu rezultata zahteve po izjavi za pravno osebo)
9	99	Sistemska napaka	Pojavi se, ko pride do notranjih napak v programski opremi IS FTS Rusije

1. Testni primeri

Zahteva za pridobitev rezultata zahteve za pridobitev izjave pravne osebe

Odgovor na zahtevo po prejemu rezultata zahteve za izjavo pravne osebe, če zahteva še ni bila obdelana

Odgovor na zahtevo po prejemu rezultata zahteve za izjavo pravne osebe s kodo vračila 53

Odgovor na zahtevo po prejemu rezultata zahteve za izjavo pravne osebe z napako (koda za obdelavo ni rezervirana)
(vrednosti atributov se spremenijo in)

Opomba: Pogoji za to napako v preskusnem okolju so bili umetno sproženi. Ta primer opisuje splošno logiko in strukturo odziva na napako. Pri preskušanju v produktivnem okolju vrnitev popolnoma enakega odziva brez zagotavljanja potrebnih pogojev ni mogoča.

1. Vmesnik mora sprejemati zahteve po HTTPS z naslovov IP podomrež:
   • 79.142.16.0, maska ​​255.255.240.0 (20)
   • 91.232.230.0, maska ​​255.255.254.0 (23)
2. Vmesnik mora obdelati parametre, ki jih sistem prenese s pomočjo metode HTTP GET.
3. Vmesnik mora oblikovati odziv sistema v formatu XML v kodiranju UTF-8.
4. Izmenjava informacij poteka v načinu "zahteva-odgovor", medtem ko odzivna hitrost ne sme presegati 60 sekund, sicer sistem prekine povezavo s časovno omejitvijo.
5. Če je pričakovano število plačil za storitve povezanega ponudnika veliko (do 10 plačil na minuto ali več), mora vmesnik podpirati večnitno komunikacijo do 10-15 hkratnih povezav.
6. Vmesnik mora sprejemati zahteve prek HTTPS na enem od naslednjih vrat TCP: 80, 81, 443, 8008, 8080, 8081, 8090, 8443, 4433. Uporaba drugih vrat ni dovoljena.

Osnovna načela vmesnika

Vse zahteve se posredujejo z metodo GET, parametri se posredujejo na poti zahteve.

Prenos podatkov o plačilu ponudniku izvede sistem QIWI Wallet v dveh fazah - preverjanje statusa naročnika in neposredno plačilo. Doda se lahko tudi predhodna faza pridobivanja dodatnih plačilnih parametrov od ponudnika, ki naročniku ponuja več storitev, da obvesti plačnika in doda plačilne parametre po izbiri plačnika.

Vrsto zahteve sistem QIWI Wallet posreduje v ukazni spremenljivki - niz, ki sprejme preverjanje vrednosti, plačilo ali getInfo:

Parametri poizvedbe

Vsi parametri so potrebni v poizvedbah, v katerih se uporabljajo.

Parameter	Oblika	Opis	Pri katerih se uporabljajo poizvedbe
txn_id	Celo število do 20 znakov	Enolični identifikator plačila v sistemu QIWI. Ta identifikator se uporablja za reševanje spornih vprašanj.	ček, plačilo
vsota	Delno število, natančno do stotink, ki se uporablja kot ločilo. (točka). Če vsota predstavlja celo število, je še vedno obloženo s piko in ničlami, na primer - 152,00.	Znesek plačila	ček, plačilo
ccy	Koda valute Alpha-3 ISO 4217	Valuta plačila	ček, plačilo
txn_date	LLLLMMDDHHMMSS	Datum plačila (datum plačila v sistemu pomeni datum prejema zahteve od stranke). Do tega datuma se izvede nadaljnja uskladitev poravnav med denarnico QIWI in ponudnikom. Na primer, stranka je 31. 12. 2010 ob 23:59:59 poslala zahtevo v sistem denarnice QIWI, sistem denarnice QIWI pa je ponudbo poslal 01.01.2011 ob 00:00:05. To lahko povzroči težave pri usklajevanju plačil, če sistem ponudnika postavi transakcijo v naslednje obračunsko obdobje. Da bi se izognili takšnim težavam, QIWI Wallet ponudniku posreduje prvotni datum plačila.	plačati
račun	Niz, ki vsebuje črke, številke in posebne znake, dolg do 200 znakov	ID naročnika. Ponudnik identificira svojega naročnika z edinstvenim identifikatorjem (številka osebnega računa, telefonska številka, prijava itd.). Preden se pošlje ponudniku, se identifikator preveri glede na regularni izraz, ki.	ček, plačilo, getInfo
ekstra	Dovoljene so številke (0-9), podčrtaj (_) in male črke (a-z)	Dodatni podatki o plačilu (dodatna polja). Te parametre lahko uporabite, če plačila ni mogoče izvesti brez dodatnih podatkov (en ID uporabnika v sistemu ponudnika ni dovolj). Na primer, vaš uporabniški ID je številka vaše kreditne kartice, vendar morate za plačilo navesti tudi datum poteka kartice. Seznam obveznih polj za prenos ponudniku mora biti naveden v.	ček, plačilo
prvId	Celo število	ID storitve v skupni sistem ponudnik.	getInfo
ime_parametra	Obliko imena in vrednosti parametrov ponudnik določi v.	Dodatni parametri za identifikacijo naročnika	getInfo

Za podporo razširljivosti in ohranitev uporabnosti ponudnika storitev v obdobju, ko so omogočene različne funkcije, ki jih zagotavlja protokol (na primer omogočanje prenosa novih podatkov o plačilu), se predvideva, da ponudnik ne preprečuje pojavljanja novih parametrov HTTP v zahtevo.

Zagotovljeno je, da pojav novih parametrov v zahtevi ne bo privedel do potrebe po spremembi obdelave zahtev s strani ponudnika, razen če se takšna sprememba logike ni dogovorila s ponudnikom.

Oblika odgovora

Ponudnik mora odgovor na zahteve vrniti sistemu v obliki XML. Splošna struktura odgovora je prikazana na zavihku na desni.

123323498 12369Bdkjh9 100.00 643 2012-04-05T12: 00: 07 0

Če katera od zahtev do ponudnika ne uspe, ponudnik vrne kodo napake v skladu z.

Informacijski sistem ponudnika ne sme vsebovati dveh uspešnih plačil z isto številko txn_id. Če sistem znova pošlje zahtevo z identifikatorjem txn_id, ki že obstaja v ponudnikovem informacijskem sistemu, mora ponudnik vrniti rezultat obdelave prejšnje zahteve.

V odgovoru so lahko prisotne naslednje oznake:

Na primer, obstaja situacija: stranka je 31. 12. 2010 ob 23:59:59 poslala zahtevo sistemu. Upoštevajoč zamudo pri obdelavi podatkov in pošiljanju informacij po komunikacijskih kanalih bo ponudnik prejel plačilo 01.01.2011 00:00:05 in bo v skladu s tem v drugem obdobju poročanja zabeležen v sistemu ponudnika. Da bi se izognili težavam z različnimi obračunskimi obdobji pri usklajevanju, mora ponudnik v svojem sistemu vrniti datum, na katerega je obračunano.

Primer zahteve za preverjanje stanja naročnikovega računa in registracijo plačila

Primer pogojev:

Ponudnikova aplikacija za plačilo payment_app se nahaja na yourservice.prv.ru, strežnik podpira povezave HTTPS na vratih 8443.

Za preverjanje stanja naročnika sistem QIWI Wallet ustvari zahtevo (glejte zavihek na desni).

DOBI / payment_app? command = check & txn_id = 1234567 & account = 4957835959 & sum = 10.45 & ccy = RUB 1234567 2016AB 10.45 RUB 0 v redu

Zahteva vsebuje parametre:

• command = check - identifikator zahteve za preverjanje statusa naročnika;

Uspešen odgovor ponudnika (glejte zavihek na desni).

Vrnjeni rezultat = 0 v zahtevo za preverjanje pomeni, da je mogoče osebni račun naročnika z ustrezno številko v polju za račun dopolniti z zneskom, navedenim v zahtevi v polju za vsoto. Po uspešnem preverjanju statusa naročnikovega računa sistem nadaljuje z oblikovanjem in pošiljanjem zahteve za obnovo stanja (zahtevek za plačilo).

Primer zahteve za dopolnitev osebnega računa

Primer pogojev:

Za potrditev plačila sistem QIWI Wallet ustvari zahtevo (glejte zavihek na desni).

DOBI / payment_app? command = pay & txn_id = 1234567 & txn_date = 20110815120133 & account = 4957835959 & sum = 10.45 & ccy = RUB HTTP / 1.1 Gostitelj: yourservice.prv.ru:8443 Odziv ponudnika 1234567 2016AB 10.45 RUB 0 v redu 2011-08-15T12: 06: 45

Zahteva vsebuje parametre:

• ukaz = plačilo - identifikator zahteve za polnjenje stanja naročnika;
• txn_id = 1234567 - interna plačilna številka v sistemu QIWI;
• txn_date = 20090815120133 - obračunski datum plačila v sistemu QIWI;
• account = 4957835959 - identifikator naročnika v informacijskem sistemu ponudnika;
• vsota = 10,45 - znesek na dobropis osebnega računa naročnika;
• ccy = RUB - valuta zneska, pripisanega na osebni račun naročnika.

Vrnjeni rezultat = 0 za zahtevo za plačilo, ponudnik obvesti o uspešnem zaključku operacije polnjenja stanja. Sistem v celoti zaključi obdelavo te transakcije.

Izbirno polje za komentar vsebuje komentar storitve.

Primer zahteve za prejem dodatnih podatkov o plačilu

Primer pogojev:

Ponudnikova aplikacija za plačilo payment_app se nahaja na yourservice.prv.ru, strežnik podpira povezave HTTPS na vratih 8443.

Za pridobitev dodatnih podatkov o plačilu sistem QIWI Wallet ustvari zahtevo (glejte zavihek na desni).

DOBI / payment_app? command = getInfo & prvId = 12345 & account = 4957835959 & name1 =% 26% 30AB & name2 = 0 HTTP / 1.1 Gostitelj: yourservice.prv.ru:8443 Odziv ponudnika račun1 izraz 2 0 v redu

Zahteva vsebuje parametre:

• command = getInfo - identifikator zahteve za prejem dodatnih podatkov o plačilu za naročnika;
• prvId = 12345 - identifikator za identifikacijo ponudnika storitev;
• account = 4957835959 - identifikator naročnika v informacijskem sistemu ponudnika;
• name1, name2 - dodatni identifikatorji naročnikov.

Za odgovor ponudnika glejte zavihek na desni.

Vrnitev rezultata = 0 v zahtevo getInfo pomeni, da je bila zahteva uspešno zaključena in so bili prejeti dodatni podatki za prikaz naročniku.

Izbirno polje za komentar vsebuje komentar storitve.

Dnevna sprava

Do 10:00 po moskovskem času sistem ustvari in na navedeni naslov pošlje elektronski register plačil, prejetih za prejšnji dan.

Register ima naslednjo strukturo:

Datum transakcije (Moskva); Datum poročila; Vrsta; Številka transakcije; ID valute transakcije; Znesek transakcije; Komentar trgovca; Številka transakcije / računa trgovca; Datum izdaje računa; ID QW; račun; ID vračila

;; Plačilo; ;;;;;;;;

;; Plačilo; ;;;;;;;;

Polja so ločena z znakom; , delček vsote je ločen s piko, datum / čas - Moskva, vir vrstice je lahko sestavljen iz znakov x0D x0A ali samo x0D.

Na primer:

31.02.2005 00:04:00;31.02.2005

00: 00: 00; Plačilo; 3464968222; USD; 5,00 ;;;;; 0957835959 ;;

31.02.2005 00: 04: 00; 31.02.2005 00: 00: 00; Plačilo; 3464968912; RUB; 10,34 ;;;;; [zaščiteno po e -pošti];;

31.02.2005 00: 11: 00; 31.02.2005 00: 00: 00; Plačilo; 3464974548; EUR; 4,72 ;;;;; ABC-12345 ;;

Sistem vključuje le uspešna plačila v register.

Potrjena plačila se štejejo za plačila, ki so prišla tako pri spletni izmenjavi sporočil kot v registru.

Če register ne vsebuje plačil, ki so bila izvedena v zbirki ponudnikov, ali vsebuje plačila, ki niso v bazi ponudnikov, ali če register ni prejet, se morate do 12.00 obrniti na kontaktno osebo QIWI, navedeno v pogodbi. razjasniti situacijo in sprejeti odločitev.

Dodatne možnosti za avtorizacijo zahtev

Ponudnik lahko v vlogi za povezavo navede identifikator (prijavo) in skrivno geslo, ki se uporablja za avtorizacijo pri vložitvi zahtev iz QIWI.

Te podatke o avtorizaciji posreduje standardna pravila osnovno preverjanje pristnosti za zahteve HTTP (S). Glava pooblastila HTTP je dodana zahtevi. Glava vsebuje osnovno vrstico (s presledkom na koncu) in par "prijava: geslo", kodiran v BASE64:

Dovoljenje: Osnovno ***

BASE64 ("Prijava: Geslo") = "***"

Aplikacija za povezavo (vzorec)

Seznam kod za dokončanje

Pri obdelavi zahtev iz sistema mora ponudnik vse napake, ki se pojavijo v njegovi aplikaciji, uskladiti s spodnjim seznamom in vrniti ustrezne kode v elementu.

Znak + v stolpcu »smrtnost« označuje znak usodne napake. Za sistem denarnice QIWI usodna napaka pomeni, da bo ponovna pošiljanje zahteve z enakimi parametri povzročila 100 -odstotno ponovitev iste napake - zato sistem preneha obdelati zahtevo odjemalca in jo konča z napako.

Napaka, ki ni usodna, pomeni za sistem, da bo ponavljanje zahteve po istih parametrih po določenem časovnem obdobju verjetno privedlo do uspeha. Sistem bo znova poskusil zahteve, ki ne uspejo z napako, ki ni usodna, in nenehno povečeval interval, dokler operacija ne uspe ali ne uspe, ali dokler zahteva ne poteče - 24 ur.

Neuspeh pri komunikaciji s strežnikom ponudnika je napaka, ki ni usodna.

Manjka element v odzivu (neveljaven XML, storitev začasno nedostopna itd.) Je tudi napaka, ki ni usodna.

Koda