1. Інтерфейс повинен приймати запити за протоколом HTTPS з IP-адрес підмереж:
   • 79.142.16.0, маска 255.255.240.0 (20)
   • 91.232.230.0, маска 255.255.254.0 (23)
2. Інтерфейс повинен обробляти параметри, які передаються системою методом HTTP GET.
3. Інтерфейс повинен формувати відповідь системі в формат XMLу кодуванні UTF-8.
4. Обмін інформацією ведеться як “запит-ответ”, у своїй швидкість відповіді має перевищувати 60 секунд, інакше система розриває з'єднання по таймауту.
5. Якщо передбачувана кількість платежів за послуги провайдера, що підключається, очікується інтенсивним (до 10 платежів за хвилину і більше), необхідно, щоб інтерфейс підтримував багатопоточну комунікацію до 10-15 одночасних з'єднань.
6. Інтерфейс повинен приймати запити за протоколом HTTPS на один із наступних TCP-портів: 80, 81, 443, 8008, 8080, 8081, 8090, 8443, 4433. Використання інших портів не допускається.

Основні принципи роботи інтерфейсу

Всі запити передаються методом GET, параметри передаються шляхом запиту.

Передача інформації про платеж провайдеру здійснюється системою QIWI Wallet у два етапи – перевірка статусу абонента та проведення платежу. Також може додаватися попередній етап отримання додаткових параметрів платежу від провайдера, який надає абоненту кілька сервісів, для інформування платника та додавання параметрів платежу на вибір платника.

Тип запиту передається системою QIWI Wallet у змінній command – рядок, що приймає значення check, pay або getInfo:

Параметри запитів

Усі параметри є обов'язковими в тих запитах, в яких вони використовуються.

Для підтримки розширюваності та збереження працездатності сервісу провайдера в період включення різних функцій, передбачених протоколом (наприклад, включення передачі нових реквізитів платежу), передбачається, що провайдер не перешкоджає появі нових нових HTTP-параметрів.

Гарантується, що поява нових параметрів у запиті не призведе до необхідності зміни обробки запитів з боку провайдера, за винятком випадків, коли така зміна логіки була узгоджена з провайдером.

Формат відповіді

Провайдер повинен повернути відповідь на запити системи у форматі XML. Загальна структура відповіді наведена на вкладці праворуч.

Якщо будь-який із запитів провайдеру завершується помилкою, то провайдер повертає код помилки відповідно до .

У інформаційної системипровайдера не повинно міститися двох успішно проведених платежів з одним і тим самим номером txn_id. Якщо система повторно надсилає запит з існуючим в інформаційній системі провайдера ідентифікатором txn_id , то провайдер повинен повернути результат обробки попереднього запиту.

У відповіді можуть бути такі теги:

Наприклад, має місце ситуація: клієнт надіслав до системи запит 31.12.2010 о 23:59:59. Враховуючи затримку на обробку даних та пересилання інформації каналами зв'язку, провайдером платіж буде отримано 1.01.2011 00:00:05 і, відповідно, враховано в системі провайдера в іншому звітному періоді. Щоб при проведенні звірок проблем із різними звітними періодами не виникало, необхідно, щоб провайдер повертав дату, за якою здійснюється облік у його системі.

Приклад запиту на перевірку стану рахунку абонента та реєстрацію платежу

Умови прикладу:

Платіжна програма провайдера payment_app розташовується за адресою yourservice.prv.ru, сервер підтримує HTTPS з'єднання по порту 8443.

Для перевірки стану абонента система QIWI Wallet генерує запит (див. вкладку праворуч).

Запит містить параметри:

• command=check – ідентифікатор запиту перевірку стану абонента;

Успішна відповідь провайдера (див. вкладку праворуч).

Повернення result=0 на запит check свідчить про те, що особовий рахунок абонента з відповідним номером в полі account може бути поповнений на суму, зазначену в запиті в полі sum . Після успішної перевірки стану рахунку абонента система переходить до формування та надсилання запиту на поповнення балансу (запит pay).

Приклад запиту на поповнення особового рахунку

Умови прикладу:

Для підтвердження платежу система QIWI Wallet генерує запит (див. вкладку праворуч).

Запит містить параметри:

• command=pay – ідентифікатор запиту поповнення балансу абонента;
• txn_id=1234567 – внутрішній номер платежу системі QIWI;
• txn_date=20090815120133 – дата обліку платежу у системі QIWI;
• account=4957835959 – ідентифікатор абонента в інформаційній системі провайдера;
• sum=10.45 – сума до зарахування на особовий рахунок абонента;
• ccy = RUB – валюта суми зарахування на особовий рахунок абонента.

Повертаючи result=0 на запит pay, провайдер повідомляє про успішне завершення операції поповнення балансу. Система повністю завершує обробку цієї транзакції.

У необов'язковому полі comment міститься службовий коментар.

Приклад запиту отримання додаткових даних платежу

Умови прикладу:

Платіжна програма провайдера payment_app розташовується за адресою yourservice.prv.ru, сервер підтримує HTTPS з'єднання на порт 8443.

Для отримання додаткових даних платежу система QIWI Wallet генерує запит (див. вкладку праворуч).

Запит містить параметри:

• command=getInfo – ідентифікатор запиту на отримання додаткових даних платежу для абонента;
• prvId=12345 – ідентифікатор визначення сервісу провайдера;
• account=4957835959 – ідентифікатор абонента в інформаційній системі провайдера;
• name1 , name2 – додаткові ідентифікатори абонента.

Відповідь провайдера див. на вкладці праворуч.

Повернення result=0 на запит getInfo свідчить, що запит виконано успішно та додаткові дані для відображення абоненту отримано.

У необов'язковому полі comment міститься службовий коментар.

Щоденна звірка

До 10:00 за московським часом система генерує та відправляє за вказаною адресою електронний реєстр прийнятих платежів за попередній день.

Реєстр має таку структуру:

Transaction date (Москва);

;;Payment; ;;;;;;;;

;;Payment; ;;;;;;;;

Поля розділені знаком; , Дробова частина суми відокремлена точкою, дата/час – Московські, переклад рядка може складатися як із символів x0D x0A, так і просто з x0D.

Наприклад:

31.02.2005 00:04:00;31.02.2005

00:00:00;Payment;3464968222;USD;5.00;;;;;0957835959;;

31.02.2005 00:04:00;31.02.2005 00:00:00;Payment;3464968912;RUB;10.34;;;;;; [email protected];;

31.02.2005 00:11:00;31.02.2005 00:00:00;Payment;3464974548;EUR;4.72;;;;;ABC-12345;;

Система включає до реєстру лише успішно проведені платежі.

Підтвердженими вважаються платежі, які прийшли як під час онлайн обміну повідомленнями, так і в реєстрі.

Якщо в реєстрі відсутні платежі, які проведені в базі провайдера, або містяться платежі, яких немає в базі провайдера, або при неодержанні реєстру, необхідно зв'язатися з контактною особою QIWI, зазначеною в договорі, до 12:00 для з'ясування ситуації та прийняття рішення.

Додаткові можливості авторизації запитів

У заявці на підключення провайдер може задати ідентифікатор (логін) та секретний пароль до нього, які використовуються для авторизації при запитах QIWI.

Ці авторизаційні дані передаються за стандартними правилами basic-аутентифікації при запитах HTTP(S). До запиту додається HTTP-заголовок Authorization. У заголовку вказується рядок Basic (з пропуском на кінці) та пара “логін:пароль”, закодована в BASE64:

Authorization: Basic ***

BASE64("Login:Password") = "***"

Заявка на підключення (зразок)

Список кодів завершення

При обробці запитів від системи, провайдер повинен зіставити всі помилки, що виникають у його додатку, з наведеним нижче списком і повертати відповідні коди в елементі.

Знак + у стовпці "фатальність" вказує на ознаку фатальності помилки. Для системи QIWI Wallet фатальна помилка означає, що повторне надсилання запиту з тими самими параметрами призведе до 100% повторення тієї ж помилки – отже, система припиняє обробку клієнтського запиту та завершує його з помилкою.

Нефатальна помилка означає для системи, що повторення запиту з тими самими параметрами через деякий проміжок часу може призвести до успіху. Система повторюватиме запити, що завершуються нефатальною помилкою, постійно збільшуючи інтервал, доки операція не завершиться успіхом або фатальною помилкою, або поки не закінчиться термін життя запиту – 24 години.

Відсутність зв'язку із сервером провайдера є нефатальною помилкою.

Відсутність у відповіді елемента (некоректний XML, сторінка Service temporarily unavailable тощо) також є нефатальною помилкою.

Загальні відомості

1. Опис вихідних параметрів

Вихідні дані: XML документ за схемою WS_ULIPOTVID_2_311_09_04_02_01.XSD

Параметри комплексного типу описані у додатку "Опис загальних структур даних" (у пунктах 10, 6, 9).

1. Коди повернень

1. Контрольні приклади

Відповідь на запит на отримання результату запиту на отримання виписки з ЮЛ, у разі запит ще не опрацьовано

Відповідь на запит на отримання результату запиту на отримання виписки за ЮЛ із кодом повернення 53

Відповідь на запит на отримання результату запиту на отримання витягу з ЮЛ з помилкою (код обробки якої не зарезервований)
(Змінюються значення атрибутів і)

Примітка: умови виникнення цієї помилки в тестовому середовищі були штучно ініційовані. Даний приклад описує загальну логіку та структуру відповіді з помилкою. При проведенні випробувань на продуктивному середовищі повернення точно такої ж відповіді без забезпечення необхідних умов неможливе.

Перевірка здійснюється для того, щоб переконатися, що рахунок та наступний платіж можуть бути коректно опрацьовані на стороні Проекту.

При спрощеній інтеграції перевірка ідентифікатора користувача та замовлення відбувається двічі: під час переходу на форму оплати та при виборі платіжного методу.

Проекту необхідні:

• URL-адреси перевірки ідентифікатора або замовлення користувача(Вказати в Технічних налаштуваннях в Особистому кабінеті);
• Обробник, здатний прийняти та розпізнати параметри запиту від Системи та відповісти так, як того очікує Система.

Якщо перевірка ідентифікатора після виставлення рахунку завершилася з помилкою, рахунок виставлено не буде, а користувач переадресується на сторінку помилки платежу, вказану проектом за допомогою параметра return_url_failабо в Технічному налаштуванні (якщо сторінка не вказана - використовується аналогічна на стороні Системи). На сторінку помилки платежу методом GET автоматично надсилається параметр err_msgзі значенням "Такого персонажа не існує".

Параметри запиту від Системи до Проекту

Система надсилає Проекту запит на URL-адресу перевірки ідентифікатора або замовлення користувача, зазначений у Технічних налаштуваннях в Особистому кабінеті.

• метод передачі - POST;
• кодування - UTF-8.

Параметри відповіді Проекту

На запит Системи від Проекту має надходити відповідь.

Для передачі параметрів запиту використовуються такі правила:

• формат - XML;
• кодування - UTF-8.

Приклад відповіді на запит перевірки ідентифікатора користувача або замовлення

YES

Приклад мінімального обробника запитів Системи під час перевірки ідентифікатора користувача або замовлення

//Генерація відповіді function sendResponse($status, $message = "")( $response = ""."\n"; $response .= " "."\n"; $response .= " ".$status.""."\n"; $response .= " ".$message.""."\n"; $response .= ""; die($response); ) //Перевірка існування ідентифікатора користувача або замовлення function checkUser($userID)( $sql = "SELECT login FROM users WHERE usr_id = ".intval($userID); $query = mysql_query($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["amount"].$_POST["userid"].$_POST["paymentid"].$secretKey); if($projectHash != $_POST["key"])( sendResponse("NO", "Контрольний підпис запиту неправильний."); ) if(floatval($_POST["amount"]) == 0 && intval($ _POST["paymentid"]) == 0)( //Запит на перевірку ідентифікатора користувача або замовлення if(checkUser($_POST["userid"]))( sendResponse("YES", "Ідентифікатор існує"); ) else( sendResponse("NO", "Ідентифікатор не знайдений"); ) )

Унікальний ідентифікатор платежу – що це? Навіщо він потрібний? Це найбільш часті питання, які ставлять підприємці при сплаті податків у банку, коли банківський службовець вимагає вказати цей викликає подив. Де його дізнатись, як отримати і чи можна без нього обійтися? Так, інструмент, створений для спрощення процедури, призвів до того, що виникли нові питання, які потрібно роз'яснити.

Що таке унікальний ідентифікатор?

Унікальний ідентифікатор платежу - це 20-значний код, який необхідно вказувати при погашенні заборгованості з податків. Це дає можливість безперешкодно та швидко сплатити податки з особистого кабінету на сайті податкової служби. Такий підхід значно спрощує та прискорює процедуру проведення операції. Оплата відбувається швидко, а значить, своєчасно, що дозволяє уникнути затримок, а отже, штрафних санкцій та пені.

Використання унікального ідентифікатора дає можливість підприємцям, юридичним та фізичним особамсплачувати податки зручним для себе способом. Але отримання та заповнення форми податкової документації у разі має свої особливості, які доводиться враховувати. Проблема полягає ще й у тому, що сам державний інформаційний сервіс має складну заплутану структуру, в якій не може розібратися навіть досвідчений користувач.

Навіщо він потрібний?

Він потрібний для того, щоб у ФНП знали, коли і від якої особи надійшли гроші на рахунок. У ГІС зареєстровано мільйони користувачів, визначити, від кого і на які цілі переказуються гроші, складно. Саме тому наказом Мінфіну №107н від 12.11.13 року було змінено правила, відповідно до яких з'явився окремий для податків унікальний ідентифікатор платежів нарахування.

Для податкової служби він потрібний для того, щоб більш ефективно проводити фіскальну політику та виявляти злісних неплатників. Юридичним та фізичним особам потрібен як найбільш зручний і швидкого способусплатити податки. У результаті уряд може контролювати дії податківців та припиняти випадки, коли їхні дії перевищують передані їм повноваження, що нерідко траплялося раніше. Бізнесмени менш залежать від волі окремого та страждають від незаконних поборів. Скоротилася кількість перевірок, що проводяться.

Хто його має вказувати?

Вказувати унікальний ідентифікатор платежів можуть як пересічні громадяни, підприємці (фізичні особи), і юридичні особи. Робити це можна при сплаті податків безпосередньо у кабінеті інформаційної системи чи через банк. При переказі слід враховувати, що платіж через Ощадбанк має особливості. Вони мають свою особливу форму, під час заповнення якої унікальний ідентифікатор не треба вказувати. УІН вказується при сплаті податків, держмита через сервіс "Держпослуги" або відділення банку.

Якщо фізична чи юридична особа заповнює платіжні документи на сплату податків і зборів, строк сплати яких ще не закінчився, то вона може не вписувати унікальний ідентифікатор, а в терміні введення реквізиту вставити нуль. Хоча законом такий спосіб заповнення рядка допускається, при оплаті через банк службовець може вимагати заповнення рядка 20-значним номером платежу та вправі відмовитися прийняти платіж. Тому важливо знати, у яких випадках його треба вказувати, а яких це не обов'язково.

У яких випадках його потрібно вказувати?

Слід зауважити, що ідентифікатор не завжди потрібно вказувати, а лише у певних випадках, описаних у правилах та положеннях Банку Росії (зокрема, положення №383-П). УІН - унікальний ідентифікатор вказується у двох випадках:

1. Якщо він був вказаний одержувачем коштів та наданий фізичному або юридичній особі, що зобов'язаний їх сплатити відповідно до умов договору. У такому разі ідентифікатор надається автоматично.
2. При перерахуванні коштів у податкові органи. Підприємець або фізична особа заповнює спеціальні поля (рядки) платіжки у паперовому або електронному вигляді. І тут заповнення викликає деякі труднощі. Адже підприємець не завжди знає свій номер унікального ідентифікатора платежу, де взяти його.

У другому випадку більшість платників податків зазнають труднощів, тому що не знають, де можна взяти і де вказати в документі. А неправильно зазначені дані призводять до затримки платежу, пені та штрафів.

Де та як можна отримати ідентифікатор?

Про унікальний ідентифікатор платежів, як дізнатися інформацію, а також про те, чи було прийнято платіж? Перевірити це можна як у особистому кабінетіДВС після реєстрації в системі, так і при отриманні платіжного доручення у разі прострочення платежів. Але це крайній випадок. Підприємцю буде відомий номер із документів, що вказують на наявність заборгованості чи штрафу перед податковими органами.

Якщо прострочених платежів не було, а УІН вказати треба, достатньо відправити запит до податкової служби, щоб отримати номер.

Як правильно заповнити?

При сплаті платниками податків платежів у бюджетну системуРФ заповнюють платіжне доручення. У ньому крім унікального ідентифікатора підприємець має зазначити:

• БІК тієї установи, через яку буде здійснено платіж;
• найменування банку, його юридичну адресу;
• розрахунковий рахунок, з якого проводитиметься переказ;
• вид оплати (код);
• дата проведення операції.

Номер вводять у рядок унікального ідентифікатора платежу – 22 (код поля). Не заповнюють лише тому випадку, якщо платіж відбувається своєчасно. У такому разі в цьому рядку проставляють 0 (нуль).

Що робити, якщо документ уже містить УІН?

Іноді, особливо під час здійснення платежів через спеціалізовані інформаційні системи, при заповненні доручення в електронному вигляді у рядку (її код 22) унікальний ідентифікатор платежу з'являється сам. Як до цього поставитися? Чи вважати це помилкою, якщо грошові коштивносяться своєчасно? Насправді жодної помилки немає. Можна сплатити як із зазначенням номера ідентифікатора, так і простовивши в рядку «0». Просто ідентифікатор вимагають вказати під час прострочення платежу, тобто на вимогу податкової.

Хоча й можна платити без розмежувань, проте такий підхід є небажаним. Підприємство повинне розмежовувати звичайні податкові платежі та ті, що були сплачені на вимогу податківців. Це допоможе уникнути плутанини у звітності.

Але навіть якщо не вдалося дізнатися та вказати в дорученні ідентифікатор, це не дає право банкам відмовлятися приймати його. Банк зобов'язаний прийняти та переказати кошти, навіть якщо не зазначено УІП (унікальний ідентифікатор платежу). Правило це прописане у офіційних документах податкової служби. У ньому цілком ясно зазначено, що фізичній чи юридичній особі достатньо вказати свій ІПН, а в рядку (код 22) унікального ідентифікатора платежу вписати «0». У разі банк немає права відмовитися від переказу платежу. Але підприємець має враховувати, що у разі помилки чи затримки банк не несе відповідальності.

Що означає код: розшифрування ідентифікатора

Ідентифікатор розшифровується так:

1. Числа з 1 по 3 позначають код податкового підрозділу, до якого надійдуть кошти.
2. Цифра 4 означає вид платежу. На цьому місці завжди стоїть нуль.
3. Числа з 5 до 19. Позначають код документа в системі оподаткування. Кожному платнику надається свій особливий код, заснований на колишньої версіїіндекс документа.
4. Цифра 20. За її номером визначається яким державним органом влади здійснюється перевірка платежу. Розраховується з урахуванням решти 19 цифр коду.

Унікальний ідентифікатор платежу ідентичний індексу документа лише у випадку, якщо індекс складається із 20 цифр.

Що буде, якщо його не вказати?

За номером УІН проводиться облік податків та інших платежів до бюджету автоматично. Інформація про платежі до бюджету передається до єдиної бази даних. Якщо вказати неправильний код або не вказати його, система не розпізнає платіж, і гроші не будуть переведені. Це може призвести до таких неприємностей, як:

• у компанії виникне заборгованість перед бюджетом та фондами;
• продовжать нараховувати пені;
• потрібно уточнювати платіж та з'ясовувати його долю;
• гроші надійдуть до бюджету чи фондів із запізненням.

Якщо у бізнесмена немає або він не знає унікального ідентифікатора платежу, де взяти, він може скористатися службою підтримки в ДВС у будь-який час, а не чекати, коли податкові органи вживуть заходів. Якщо підприємець не має доступу до інтернету та до електронної системи"Держпослуги", він може надіслати звичайний лист до найближчого відділення податкової служби або з'явитися особисто для отримання ідентифікатора.

Які документи необхідні для отримання ідентифікатора?

Все залежить від того, в якій формі буде складено документ та як оплачуватись. Якщо це паперовий документ, необхідно надіслати письмовий запит до податкового органу. У листі вказати паспортні дані, ІПН та номер СНІЛЗ. Унікальний ідентифікатор платежу надішлють у листі у відповідь. Якщо після отримання цього реквізиту юридична чи фізична особа з'явилося особисто у відділення, ці документи мають бути при ньому. Вони необхідні заповнення форм.

Для отримання реквізиту в електронному вигляді спочатку слід зареєструватися в єдиній інформаційній системі на сайті "Держпослуги", вказавши ті ж дані, що і при письмовому запиті. Після цього прийде лист на адресу місця проживання з ключем доступу. І лише після цього можна зробити запит на отримання унікального ідентифікатора. Зазвичай, ця послуга надається протягом кількох годин після заявки. Документів надавати не потрібно.

Як видно, нічого складного під час використання ідентифікатора немає. Дізнатися його не важко. Для цього не треба збирати купу документів чи довідок. Зате податки можна сплачувати у зручній формі та у будь-який час. Якщо раніше юридичним та фізичним особам доводилося витрачати час та кошти, щоб внести податкові платежі, то за його допомогою їх можна оплачувати, не виходячи з дому чи офісу, без відриву від роботи.