Weryfikacja jest przeprowadzana w celu upewnienia się, że faktura i późniejsza płatność mogą być prawidłowo przetworzone po stronie Projektu.

Dzięki uproszczonej integracji identyfikator użytkownika i zamówienie są weryfikowane dwukrotnie: przy przejściu na formę płatności i przy wyborze metody płatności.

Projekt potrzebuje:

• Identyfikator użytkownika lub adres URL weryfikacji zamówienia(określić w Ustawieniach Technicznych w Koncie Osobistym);
• Program obsługi zdolny do akceptowania i rozpoznawania parametrów żądania z Systemu i reagowania zgodnie z oczekiwaniami Systemu.

Jeżeli weryfikacja identyfikatora po zakończeniu faktury z błędem, to faktura nie zostanie wystawiona, a użytkownik zostanie przekierowany na stronę błędu płatności określoną przez projekt za pomocą parametru return_url_fail lub w ustawieniach technicznych (jeśli strona nie jest określona, ​​podobna strona jest używana po stronie Systemu). Do strony błędu płatności przy użyciu metody GET parametr jest wysyłany automatycznie err_msg ze znaczeniem „Ta postać nie istnieje”..

Zażądaj parametrów z Systemu do Projektu

System wysyła do Projektu zapytanie o adres URL do sprawdzenia identyfikatora lub kolejności użytkownika określonej w Ustawieniach Technicznych w Koncie Osobistym.

• metoda transferu - POCZTA;
• kodowanie - UTF-8.

Parametr	Opis parametrów	Format parametrów	Obowiązkowy parametr
identyfikator użytkownika	Identyfikator użytkownika lub zamówienia (równy wartości parametru) przezwisko v)	sznurek (256)	tak
userid_extra	Dodatkowe informacje wymagane do dokonania płatności lub zebrania statystyk po stronie Projektu (równe wartości parametru) nick_dodatkowy )	sznurek (500)	Nie
klucz	Podpis weryfikacyjny wniosku. Powstaje jako hash zgodnie z algorytmem md5 z połączenia następujących parametrów: wartość parametru identyfikator użytkownika, tajny klucz projektu	md5 (0userid0 tajny projekt)	tak
ilość		0	tak
identyfikator płatności	Sprawdzam żądanie czeku. Akceptuje tylko zero (ilość = 0)	0	tak
identyfikator zamówienia	Identyfikator płatności w systemie księgowym Projektu (równy wartości parametru) identyfikator_zamówienia v)	warchar (64)	Nie

Parametry odpowiedzi projektu

Projekt powinien otrzymać odpowiedź na żądanie Systemu.

Do przekazywania parametrów zapytania używane są następujące reguły:

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

Parametr	Opis parametrów	Format parametrów	Obowiązkowy parametr
kod	Poproś o kod odpowiedzi. TAK- identyfikator istnieje. NIE- identyfikator nie istnieje	(wielkość liter ma znaczenie)	tak
komentarz	Dekodowanie kodu odpowiedzi na żądanie. Przykłady tekstu: walidacja parametru userid nie powiodła się; walidacja parametru orderid nie powiodła się; walidacja parametru klucza nie powiodła się	sznurek (400)	Nie

Przykład odpowiedzi na prośbę o weryfikację identyfikatora użytkownika lub zamówienia

TAK

Przykład minimalnej obsługi żądania systemowego podczas sprawdzania identyfikatora użytkownika lub zamówienia

// Wygeneruj funkcję odpowiedzi sendResponse ($ status, $ message = "") ($ response = ""." \ n "; odpowiedź $. =" "." \ n "; odpowiedź $. =" ". $ status.""." \ n "; odpowiedź $. =" ". $ wiadomość.""." \ n "; odpowiedź $. =""; die (odpowiedź $);) // Sprawdź, czy istnieje identyfikator użytkownika lub zamówienie funkcja checkUser ($ userID) ($ sql =" SELECT login FROM users WHERE usr_id = ".intval ($ userID); $ query = mysql_query ( $ sql ); if (mysql_error ()) (zwraca FALSE;) if (mysql_num_rows ($ zapytanie) == 0) (zwraca FALSE;) zwraca TRUE;) $ secretKey = "IT \" S_A_PROJECT_SECRET_WORD "; $ projectHash = md5 ($ _ POST ["kwota"]. $ _ POST ["userid"]. $ _ POST ["paymentid"]. $ secretKey); if ($ projectHash! = $ _POST ["klucz"]) (sendResponse ("NIE", "Podpis weryfikacyjny żądania jest nieprawidłowy.");) if (floatval ($ _ POST ["kwota"]) == 0 && intval ($ _POST ["paymentid"]) == 0) (// Żądanie sprawdzenia identyfikatora użytkownika lub zamówienia, jeśli (checkUser ($ _ POST ["userid"])) (sendResponse ("YES", "ID istnieje");) else ( sendResponse ("NIE", "Nie znaleziono identyfikatora"));))

Informacje ogólne

Opis parametrów wejściowych

Dane wejściowe: Dokument XML wg schematu WS_ULIPZAPRID_2_311_11_04_02 _01_01.XSD

1. Opis parametrów wyjściowych

Wyjście: Dokument XML wg schematu WS_OTVVIPULXSD_2_311_14_04_02_01.XSD

lub

Wyjście: Dokument XML wg schematu WS_ULIPOTVID_2_311_09_04_02_01.XSD

Parametry typu złożonego są opisane w Dodatku „Opis ogólnych struktur danych” (w punktach 10, 6, 9).

1. Kody zwrotne

№	Kod powrotu	Opis kodu zwrotnego	Warunki wystąpienia	Komentarz
1	01	Żądane informacje nie zostały znalezione.	Występuje pod warunkiem, że informacji o osobie prawnej nie ma w Jednolitym Państwowym Rejestrze Osób Prawnych
2	51	Żądanie przyjęte do przetworzenia	Występuje, gdy żądanie zostanie pomyślnie odebrane do przetworzenia
3	52	Odpowiedź nie jest gotowa	Występuje w przypadku braku odpowiedzi na żądanie pomyślnie przyjęte do przetworzenia	Używane podczas wykonywania asynchronicznego żądania
4	53	Informacje dotyczące osoby prawnej / przedsiębiorcy indywidualnego nie mogą być przekazywane w formie elektronicznej	Występuje, gdy nie można sformułować odpowiedzi na żądanie w formie elektronicznej
5	82	Błąd kontroli formatu logicznego	Występuje, gdy dokument (żądanie) nie pasuje do schematu xsd	Rezerwa, nie może być używana
6	83	Brak żądania o określonym identyfikatorze żądania i rodzaju żądanych informacji od tego organu	Występuje w sytuacji, gdy we wniosku o uzyskanie wyniku na oświadczenie o osobie prawnej wskazano błędny (nieznany) identyfikator wniosku i (lub) nie otrzymano wniosku z takim identyfikatorem z tego organu	Używany z żądaniem asynchronicznym (podczas odbierania wyniku żądania zestawienia dla podmiotu prawnego)
9	99	Błąd systemu	Występuje, gdy w oprogramowaniu IS Federalnej Służby Podatkowej Rosji występują błędy wewnętrzne

1. Przypadki testowe

Wniosek o uzyskanie wyniku wniosku o uzyskanie oświadczenia osoby prawnej”

Odpowiedź na wniosek o otrzymanie wyniku wniosku o oświadczenie osoby prawnej, w przypadku gdy wniosek nie został jeszcze rozpatrzony

Odpowiedź na prośbę o otrzymanie wyniku wniosku o oświadczenie osoby prawnej z kodem zwrotnym 53

Odpowiedź na żądanie otrzymania wyniku wniosku o oświadczenie osoby prawnej z błędem (którego kod przetwarzania nie jest zastrzeżony)
(zmiana wartości atrybutów i)

Uwaga: warunki dla tego błędu w środowisku testowym zostały sztucznie wywołane. Ten przykład opisuje ogólną logikę i strukturę reakcji na błąd. Podczas testowania w środowisku produktywnym zwrócenie dokładnie tej samej odpowiedzi bez podania niezbędnych warunków nie jest możliwe.

1. Interfejs musi akceptować żądania przez HTTPS z adresów IP podsieci:
   • 79.142.16.0, maska ​​255.255.240.0 (20)
   • 91.232.230.0, maska ​​255.255.254.0 (23)
2. Interfejs musi przetwarzać parametry przekazywane przez system za pomocą metody HTTP GET.
3. Interfejs musi stanowić odpowiedź do systemu w formacie XML w kodowaniu UTF-8.
4. Wymiana informacji odbywa się w trybie „żądanie-odpowiedź”, przy czym czas odpowiedzi nie powinien przekraczać 60 sekund, w przeciwnym razie system zerwie połączenie po przekroczeniu limitu czasu.
5. Jeśli spodziewana liczba płatności za usługi podłączonego dostawcy ma być intensywna (do 10 płatności za minutę lub więcej), interfejs musi obsługiwać komunikację wielowątkową do 10-15 jednoczesnych połączeń.
6. Interfejs musi akceptować żądania HTTPS na jednym z następujących portów TCP: 80, 81, 443, 8008, 8080, 8081, 8090, 8443, 4433. Korzystanie z innych portów jest niedozwolone.

Podstawowe zasady interfejsu

Wszystkie żądania przekazywane są metodą GET, parametry przekazywane są w ścieżce żądania.

Przekazanie informacji o płatności do dostawcy realizowane jest przez system QIWI Wallet w dwóch etapach – sprawdzenie statusu abonenta oraz bezpośrednie dokonanie płatności. Można również dodać wstępny etap uzyskiwania dodatkowych parametrów płatności od dostawcy świadczącego abonentowi kilka usług, aby poinformować płatnika i dodać parametry płatności według wyboru płatnika.

Typ zapytania przekazywany jest przez system QIWI Wallet w zmiennej command - ciągu znaków, który przyjmuje wartości check, pay lub getInfo:

Parametry zapytania

Wszystkie parametry są wymagane w zapytaniach, w których są używane.

Parametr	Format	Opis	W jakich zapytaniach są używane
txn_id	Liczba całkowita do 20 znaków	Unikalny identyfikator płatności w systemie QIWI. Ten identyfikator służy do rozwiązywania kontrowersyjnych problemów.	sprawdź, zapłać
suma	Liczba ułamkowa z dokładnością do setnych, używana jako separator. (punkt). Jeśli suma reprezentuje liczbę całkowitą, to nadal jest uzupełniona kropką i zerami, na przykład - 152,00.	Kwota płatności	sprawdź, zapłać
ccy	Kod waluty Alfa-3 ISO 4217	Waluta płatności	sprawdź, zapłać
txn_date	RRRRMMDDGGMMSS	Data płatności (data płatności w systemie oznacza datę otrzymania zapytania od klienta). Do tego dnia następuje dalsze uzgadnianie rozliczeń pomiędzy QIWI Wallet a dostawcą. Na przykład klient wysłał żądanie do systemu QIWI Wallet w dniu 31.12.2010 o godzinie 23:59:59, a system QIWI Wallet wysłał żądanie do dostawcy w dniu 01.01.2011 o godzinie 00:00:05. Może to prowadzić do problemów z uzgadnianiem płatności, jeśli system dostawcy umieści transakcję w kolejnym okresie rozliczeniowym. Aby uniknąć takich problemów, QIWI Wallet zapewnia dostawcy pierwotną datę płatności.	płacić
konto	Ciąg zawierający litery, cyfry i znaki specjalne o długości do 200 znaków	ID Subskrybera. Dostawca identyfikuje swojego abonenta za pomocą unikalnego identyfikatora (numer konta osobistego, numer telefonu, login itp.). Przed wysłaniem do dostawcy identyfikator jest sprawdzany pod kątem wyrażenia regularnego.	sprawdź, zapłać, zdobądź informacje
dodatkowy	Dozwolone są cyfry (0-9), podkreślenie (_) i małe litery łacińskie (a-z)	Dodatkowe szczegóły płatności (dodatkowe pola). Parametry te można wykorzystać, jeśli nie można dokonać płatności bez dodatkowych danych (jeden identyfikator użytkownika w systemie dostawcy nie wystarczy). Na przykład identyfikator użytkownika to numer karty kredytowej, ale aby dokonać płatności, musisz również określić datę ważności karty. Należy podać listę pól wymaganych do przesłania do dostawcy.	sprawdź, zapłać
prvId	Liczba całkowita	Identyfikator usługi w wspólny system dostawca.	zdobyć informacje
Nazwa parametru	Format nazwy i wartości parametrów jest określony przez dostawcę w pliku.	Dodatkowe parametry do identyfikacji abonenta	zdobyć informacje

W celu wsparcia rozszerzalności i utrzymania sprawności usługodawcy w okresie, w którym włączone są różne funkcje udostępniane przez protokół (np. umożliwienie przesyłania nowych szczegółów płatności), przyjmuje się, że usługodawca nie uniemożliwia pojawiania się nowych parametrów HTTP w prośba.

Gwarantuje się, że pojawienie się nowych parametrów w żądaniu nie spowoduje konieczności zmiany sposobu obsługi żądań przez dostawcę, chyba że taka zmiana logiki została uzgodniona z dostawcą.

Format odpowiedzi

Dostawca musi zwrócić odpowiedź na żądania do systemu w formacie XML. Ogólna struktura odpowiedzi jest pokazana w zakładce po prawej stronie.

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

Jeśli którekolwiek z żądań do dostawcy nie powiedzie się, dostawca zwraca kod błędu zgodnie z.

System informacyjny dostawcy nie powinien zawierać dwóch udanych płatności o tym samym numerze txn_id. Jeżeli system ponownie wyśle ​​żądanie z identyfikatorem txn_id już istniejącym w systemie informacyjnym dostawcy, dostawca musi zwrócić wynik przetworzenia poprzedniego żądania.

W odpowiedzi mogą znajdować się następujące tagi:

Na przykład jest taka sytuacja: klient wysłał żądanie do systemu w dniu 31.12.2010 o godzinie 23:59:59. Biorąc pod uwagę opóźnienie w przetwarzaniu danych i przesyłaniu informacji kanałami komunikacji, dostawca otrzyma płatność w dniu 01.01.2011 00:00:05 i odpowiednio zostanie odnotowany w systemie dostawcy w kolejnym okresie sprawozdawczym. Aby uniknąć problemów z różnymi okresami rozliczeniowymi podczas uzgadniania, konieczne jest, aby dostawca zwracał w jego systemie datę dokonania rozliczenia.

Przykład prośby o sprawdzenie stanu konta subskrybenta i zarejestrowanie wpłaty

Przykładowe warunki:

Aplikacja płatnicza dostawcy payment_app znajduje się pod adresem yourservice.prv.ru, serwer obsługuje połączenia HTTPS na porcie 8443.

Aby sprawdzić status abonenta, system QIWI Wallet generuje zapytanie (patrz zakładka po prawej).

DOSTWAĆ / payment_app? command = check & txn_id = 1234567 & account = 4957835959 & sum = 10.45 & ccy = RUB 1234567 2016AB 10.45 POCIERAĆ 0 ok

Żądanie zawiera parametry:

• komenda = check - identyfikator żądania do sprawdzenia statusu abonenta;

Pomyślna odpowiedź dostawcy (patrz zakładka po prawej).

Zwrócenie wyniku = 0 do żądania sprawdzenia oznacza, że ​​konto osobiste subskrybenta o odpowiednim numerze w polu konta może zostać uzupełnione o kwotę podaną we wniosku w polu sumy. Po pomyślnej weryfikacji stanu konta subskrybenta system przystępuje do tworzenia i wysyłania prośby o uzupełnienie salda (pay request).

Przykład prośby o doładowanie konta osobistego

Przykładowe warunki:

Aby potwierdzić płatność, system QIWI Wallet generuje żądanie (patrz zakładka po prawej).

DOSTWAĆ / payment_app? command = pay & txn_id = 1234567 & txn_date = 20110815120133 & account = 4957835959 & sum = 10.45 & ccy = RUB Host HTTP / 1.1: yourservice.prv.ru:8443 Odpowiedź dostawcy 1234567 2016AB 10.45 POCIERAĆ 0 ok 2011-08-15T12: 06: 45

Żądanie zawiera parametry:

• polecenie = zapłać - identyfikator żądania uzupełnienia salda abonenta;
• txn_id = 1234567 - wewnętrzny numer płatności w systemie QIWI;
• txn_date = 20090815120133 - data rozliczenia płatności w systemie QIWI;
• account = 4957835959 - identyfikator abonenta w systemie informacyjnym dostawcy;
• suma = 10,45 - kwota do zasilenia osobistego konta subskrybenta;
• ccy = RUB - waluta kwoty zaksięgowanej na koncie osobistym subskrybenta.

Zwracając wynik = 0 dla żądania zapłaty, dostawca informuje o pomyślnym zakończeniu operacji uzupełnienia salda. System całkowicie kończy przetwarzanie tej transakcji.

Opcjonalne pole komentarza zawiera komentarz serwisowy.

Przykład prośby o dodatkowe dane do płatności

Przykładowe warunki:

Aplikacja płatnicza dostawcy payment_app znajduje się pod adresem yourservice.prv.ru, serwer obsługuje połączenia HTTPS na porcie 8443.

Aby uzyskać dodatkowe dane dotyczące płatności, system QIWI Wallet generuje żądanie (patrz zakładka po prawej).

DOSTWAĆ / payment_app? command = getInfo & prvId = 12345 & account = 4957835959 & name1 =% 26% 30AB & name2 = 0 Host HTTP / 1.1: yourservice.prv.ru:8443 Odpowiedź dostawcy konto1 termin2 0 ok

Żądanie zawiera parametry:

• command = getInfo - identyfikator żądania otrzymania dodatkowych danych płatniczych dla subskrybenta;
• prvId = 12345 - identyfikator identyfikujący usługodawcę;
• account = 4957835959 - identyfikator abonenta w systemie informacyjnym dostawcy;
• name1, name2 - dodatkowe identyfikatory abonenta.

Zobacz kartę po prawej stronie, aby uzyskać odpowiedź dostawcy.

Zwrócenie wyniku = 0 do żądania getInfo oznacza, że ​​żądanie zostało zakończone pomyślnie i otrzymano dodatkowe dane do wyświetlenia subskrybentowi.

Opcjonalne pole komentarza zawiera komentarz serwisowy.

Dzienne pojednanie

Do godziny 10:00 czasu moskiewskiego system generuje i wysyła na wskazany adres elektroniczny rejestr wpłat otrzymanych za dzień poprzedni.

Rejestr ma następującą strukturę:

Data transakcji (Moskwa); Data raportu; Typ; Numer transakcji; Identyfikator waluty transakcji; Kwota transakcji; Komentarz sprzedawcy; Numer transakcji / faktury sprzedawcy; Data wystawienia faktury; Identyfikator QW; Konto; Identyfikator zwrotu

;; Zapłata; ;;;;;;;;

;; Zapłata; ;;;;;;;;

Pola są oddzielone znakiem; , część ułamkowa sumy jest oddzielona kropką, data / godzina - Moskwa, nowy wiersz może składać się zarówno ze znaków x0D x0A, jak i po prostu z x0D.

Na przykład:

31.02.2005 00:04:00;31.02.2005

00: 00: 00; Płatność; 3464968222; USD; 5,00;;;;; 0957835959;;

31.02.2005 00:04:00;31.02.2005 00:00:00;Płatność;3464968912;RUB;10.34;;;;;; [e-mail chroniony];;

31.02.2005 00: 11: 00; 31.02.2005 00: 00: 00; Płatność; 3464974548; EUR; 4,72 ;;;;; ABC-12345 ;;

System uwzględnia tylko udane płatności w rejestrze.

Potwierdzone płatności są uważane za płatności, które przyszły zarówno w ramach wymiany wiadomości online, jak i w rejestrze.

Jeżeli rejestr nie zawiera płatności, które są dokonywane w bazie dostawcy lub zawiera płatności, których nie ma w bazie dostawcy lub jeśli rejestr nie został odebrany, należy skontaktować się z osobą kontaktową QIWI określoną w umowie do godziny 12:00 do godz. wyjaśnij sytuację i podejmij decyzję.

Dodatkowe opcje autoryzacji wniosków

We wniosku o połączenie dostawca może ustawić do niego identyfikator (login) oraz tajne hasło, które służą do autoryzacji przy składaniu żądań z QIWI.

Te dane autoryzacyjne są przesyłane przez standardowe zasady podstawowe uwierzytelnianie dla żądań HTTP (S). Do żądania dołączony jest nagłówek HTTP Authorization. Nagłówek zawiera linię Basic (ze spacją na końcu) oraz parę „login:hasło”, zakodowane w BASE64:

Autoryzacja: Podstawowa ***

BASE64 („Login: Hasło”) = „***”

Aplikacja połączenia (przykład)

Lista kodów ukończenia

Podczas przetwarzania żądań z systemu dostawca musi dopasować wszystkie błędy występujące w jego aplikacji do poniższej listy i zwrócić odpowiednie kody w elemencie.

Znak + w kolumnie krytycznej oznacza znak błędu krytycznego. Dla systemu QIWI Wallet błąd krytyczny oznacza, że ​​ponowne wysłanie żądania z tymi samymi parametrami spowoduje 100% powtórzenie tego samego błędu – w związku z tym system przestaje przetwarzać żądanie klienta i kończy je z błędem.

Błąd niekrytyczny oznacza dla systemu, że powtórzenie żądania z tymi samymi parametrami po określonym czasie może prowadzić do sukcesu. System będzie ponawiać żądania, które kończą się niepowodzeniem z błędem niekrytycznym, stale zwiększając interwał do momentu powodzenia lub niepowodzenia operacji lub do wygaśnięcia żądania — 24 godziny.

Brak komunikacji z serwerem dostawcy jest błędem niekrytycznym.

Brak elementu w odpowiedzi (nieprawidłowy kod XML, strona chwilowo niedostępna usługi itp.) również jest błędem niekrytycznym.

Kod