подключение qiwi к сайту php
Подключение qiwi к сайту php
Universal payments API PHP SDK
PHP SDK модуль для внедрения единого платежного протокола эквайринга и QIWI Кошелька.
Установка и подключение
Установка с помощью composer:
Пошаговое руководство по работе с SDK (для физических лиц): https://developer.qiwi.com/ru/p2p-sdk-guide/#integration-sdk
API P2P-счетов (для физических лиц): https://developer.qiwi.com/ru/p2p-payments
API QIWI Кассы (для юридических лиц): https://developer.qiwi.com/ru/bill-payments
Смена SECRET_KEY на новый:
Простой способ для интеграции. При открытии формы клиенту автоматически выставляется счет. Параметры счета передаются в открытом виде в ссылке. Далее клиенту отображается платежная форма с выбором способа оплаты. При использовании этого способа нельзя гарантировать, что все счета выставлены мерчантом, в отличие от выставления по API.
Подробное описание параметров для выставления счёта представлено в руководстве по использованию SDK, а так же в документации для физ.лиц и для юр. лиц
Информация о счете
Метод getBillInfo возвращает информацию о счете. В параметрах нужно указать идентификатор счета billId внутри вашей системы, в результате будет получен ответ со статусом счета. Подробнее в документации — для физ.лиц, для юр.лиц.
Отмена неоплаченного счета
Метод cancelBill отменяет неоплаченный счет. В параметрах нужно указать идентификатор счета billId внутри вашей системы, в результате будет получен ответ с информацией о счете. Подробнее в документации — для физ.лиц, для юр.лиц.
! Метод недоступен для физических лиц
В результате будет выведена информация о возврате и о счете:
Информация о возврате
! Метод недоступен для физических лиц
В результате будет выведена информация о возврате:
Тестирования без истользования реального API:
Условия использования
Последнее обновление: 09-09-2021
Для подключения на свой сайт сервиса приема переводов для физических лиц p2p необходимо иметь QIWI Кошелек со статусом идентификации «Основной» или «Профессиональный». Если Ваш кошелек имеет статус «Анонимный» – пройдите идентификацию удобным для вас способом. Для получения «Основного» статуса достаточно указать паспортные данные, для получения «Профессионального» статуса необходимо пройти очную идентификацию.
Рекомендуем получить «Профессиональный» статус. Такой статус имеет повышенные лимиты на остаток на балансе, сумму платежей и переводов в месяц, максимальную сумму одной операции. Подробнее про лимиты.
Рекомендуем ознакомиться с частыми вопросами по нашему сервису, а также с информацией о том, как избежать блокировки кошелька.
Активация p2p
Поздравляем! Вы можете приступить к интеграции.
Для работы API потребуются публичный и секретный ключи. Ключи создаются в разделе «API».
Схема работы с API
Пользователь формирует счет на вашей стороне.
Вы перенаправляете пользователя на платежную форму для выставления счета. Или выставляете счет по API и перенаправляете пользователя на созданную платежную форму.
Пользователь выбирает способ перевода и подтверждает перевод. По умолчанию подбирается оптимальный для пользователя способ перевода.
После перевода по счету вы получаете уведомление (предварительно настройте отправку уведомлений в Личном кабинете при создании ключей). Уведомления о переводе по счету содержат параметры авторизации, которые необходимо проверять на Вашем сервере.
Готовые решения
SDK и библиотеки
С руководством по работе с SDK можно ознакомиться здесь.
Решения для CMS
Авторизация
Ваши запросы авторизуются посредством секретного ключа API ( SECRET_KEY ). Параметр авторизации указывается в заголовке Authorization, значение которого формируется как «Bearer SECRET_KEY».
Публичный ключ ( PUBLIC_KEY ) используется для выставления счетов через форму.
Ключи создаются в личном кабинете на вкладке API после авторизации на p2p.qiwi.com.
Для выпуска пары ключей выполните следующие шаги:
Внизу страницы нажмите на кнопку Настроить.
Придумайте название паре ключей, чтобы упростить поиск в списке.
Подключите уведомления об оплате счетов, отметив Использовать эту пару ключей для серверных уведомлений об изменении статусов счетов.
В поле URL сервера для уведомлений укажите адрес вашего сервера, который будет обрабатывать уведомления об оплате, и нажмите на кнопку Создать.
Скопируйте в буфер секретный ключ и сохраните его в безопасном месте — в дальнейшем он не будет отображаться в интерфейсе. Используйте секретный ключ для запросов к API.
Выставление счета через форму
Простой способ для интеграции. При открытии формы клиенту автоматически выставляется счет. Параметры счета передаются в открытом виде в ссылке. Далее клиенту отображается форма с выбором способа перевода. При использовании этого способа нельзя гарантировать, что все счета выставлены вами, в отличие от выставления по API.
REDIRECT →
URL https://oplata.qiwi.com/create
Параметры
Взаимодействие через API
1. Выставление счета
Доступно выставление счетов в рублях и тенге.
Также существует более простой способ выставления счета — непосредственно через вызов платежной формы
Запрос → PUT
URL https://api.qiwi.com/partner/bill/v1/bills/HEADERS
Ответ ←
Пример тела ответа при ошибке
HEADERS
2. Проверка статуса перевода по счету
Пример тела ответа при ошибке
Метод позволяет проверить статус перевода по счету. Рекомендуется его использовать после получения уведомления о переводе.
Запрос → GET
URL https://api.qiwi.com/partner/bill/v1/bills/HEADERS
Ответ ←
Пример тела ответа при ошибке
HEADERS
3. Отмена неоплаченного счета
Пример тела ответа при ошибке
Метод позволяет отменить счет, по которому не был выполнен перевод.
Запрос → POST
URL https://api.qiwi.com/partner/bill/v1/bills//reject
HEADERS
Ответ ←
Пример тела ответа при ошибке
HEADERS
Статусы оплаты счетов
Статус | Описание | Финальный |
---|---|---|
WAITING | Счет выставлен, ожидает оплаты | — |
PAID | Счет оплачен | + |
REJECTED | Счет отклонен | + |
EXPIRED | Время жизни счета истекло. Счет не оплачен | + |
Уведомления о переводе по счету
Адрес сервера для уведомлений указывается в личном кабинете p2p.qiwi.com при генерации ключей.
Перед началом работы с сервисом уведомлений прочитайте условия по интеграции API уведомлений.
Пулы IP-адресов, с которых сервисы QIWI отправляют уведомления:
Если ваш сервер обработки уведомлений работает за брандмауэром, необходимо добавить эти IP-адреса в список разрешенных адресов входящих TCP-пакетов.
Запрос ← POST
Уведомление представляет собой входящий POST-запрос.
Тело запроса содержит JSON-сериализованные данные счета (кодировка UTF-8).
HEADERS
Авторизация уведомлений
Алгоритм проверки подписи:
Объединить значения следующих параметров уведомления в одну строку с разделителем | :
где <*>– значение параметра. Все значения при проверке подписи должны трактоваться как строки.
Вычислить HMAC-хэш c алгоритмом хэширования SHA256:
hash = HMAС(SHA256, invoice_parameters, secret_key) Где:
Сравнить значение заголовка X-Api-Signature-SHA256 с результатом из п.2.
Строка и ключ подписи кодируются в UTF-8.
Данные
В уведомлении содержится информация о счете.
Поле | Описание | Тип |
---|---|---|
bill | Данные о счете | Object |
billId | Уникальный идентификатор счета в вашей системе, указанный при выставлении | String(200) |
siteId | Ваш идентификатор в системе p2p.qiwi | String |
amount | Данные о сумме счета | Object |
amount.value | Сумма счета, округленная до двух десятичных знаков в меньшую сторону | Number(6.2) |
amount.currency | Идентификатор валюты суммы счета (Alpha-3 ISO 4217 код) | String(3) |
status | Данные о статусе счета | Object |
status.value | Строковое значение статуса | String |
status.changedDateTime | Дата обновления статуса. Формат даты ГГГГ-ММ-ДДTЧЧ:ММ:ССZ | String |
customer | Данные о пользователе | Object |
customer.phone | Номер телефона (если был указан при выставлении счета) | String |
customer.email | E-mail пользователя (если был указан при выставлении счета) | String |
customer.account | Идентификатор пользователя в вашей системе (если был указан при выставлении счета) | String |
creationDateTime | Дата создания счета. Формат даты ГГГГ-ММ-ДДTЧЧ:ММ:ССZ | String |
expirationDateTime | Срок оплаты счета. Формат даты ГГГГ-ММ-ДДTЧЧ:ММ:СС+ЧЧ:ММ\-Z | String |
comment | Комментарий к счету | String(255) |
customFields | Дополнительные данные счета (если были указаны при выставлении счета). | Object |
version | Версия уведомлений | String |
Ответ →
HEADERS
После того, как был получен входящий запрос-уведомление, необходимо проверить подлинность цифровой подписи и отправить ответ.
Настройки формы и счета
При выставлении счета через API в ответе приходит payUrl с ссылкой на форму. К ссылке можно добавить следующие параметры:
Добавьте реферальные ссылки для платежей с сайта. Полная ссылка подтвердит реальность сайта и позволит избежать проблем с блокировкой кошелька. Платежи, проходящие со страницы без заголовка запроса Refer будут приводить к блокировке кошелька. Подробнее читайте в статье Как передавать реферальные ссылки.
Пример передачи реферальной ссылки
Персонализация
Вы можете настроить персонализированную форму оплаты – изменить свое имя на название магазина и настроить цвет фона и кнопок.
Перейдите в личном кабинете в раздел Форма приема переводов, нажмите на кнопку Настроить, произведите настройку и нажмите на кнопку Сохранить.
Пример передачи параметра при вызове платежной формы
Пример передачи параметра в запросе к API
Обратите внимание, что значение themeCode индивидуально для разных кошельков.
Для применения стиля к платежной форме:
Checkout Popup
Пример работы popup
Всплывающее окно (popup) позволяет открыть форму перевода поверх вашего сайта.
В библиотеке доступно два метода: открытие существующего счета и открытие вашей формы приема переводов.
Установка и подключение:
Открытие существующего счета
Пример открытия уже созданного счета в popup
Открытие персонализированной формы
Пример открытия персонализированной формы
Хочу рассказать вам про такой class как Qiwi API Class PHP, точнее класс называется просто Qiwi API Class. Служит он для упрощения работы с API системой Qiwi. Данный класс облегчит разработку при необходимости использовать API от Qiwi. Чем он поможет? Да все просто, в классе есть все необходимое для работы с персональным кошельком, причем все запросы готовы к использованию и вам нужно лишь только правильно воспользоваться ими. Давайте разберемся в нем более детально (ссылка для скачивания класса в конце статьи).
Как работает Qiwi API Class PHP:
Класс авторизуется в кошельке через специальное API от Qiwi, то есть вам не нужно вводить никакие пароли и светить ими, ожидаю что их сопрут. Все работает на уровне самого Qiwi, то есть через официальное API. Что на мой взгляд достаточно удобно, нежели как раньше некоторые использовали Curl, для получения и обработки данных с кошелька.
Ранее я сказал, что класс нужен для работы с персональным кошельком, да это действительно так. Он работает только с персональным кошельком, причем вам не нужно проходить идентификацию и не нужно подключаться к ishop от qiwi.
Для работы с классом вам потребуется само собой qiwi кошелек, а именно номер киви кошелька и его token. Как получить токен говорить я не буду, в официальной документации все есть, причем вполне понятно и подробно.
Доступные методы:
Установка и подключение Qiwi API Class:
1. Скачайте архив с классом
2. Скопируйте Qiwi.php из папки src/ и подключите его в вашем скрипте:
Получение последних 50 записей из истории платежей за 30 дней:
Получение данных по определенной транзакции:
Вот собственно и все, с остальными методами работать можно по той же аналогии, что и с примерами выше. Если что-то непонятно будет, пишите в комментариях, также если найдете какие-то ошибки в работе класса пишите, буду исправлять по мере поступления и по мере свободного времени. Также если у вас есть предложения по расширению и обновлению класса, то пишите, будем вместе думать как лучше все сделать и стоит ли это того. Скачать самую последнюю версию класса вы можете по ссылке ниже, она ведет на GitHub, где всегда будет последняя версия. На этом все, всем спасибо за внимание.
Версия Qiwi API: Версия 1.4 от 15.05.2018
Версия Qiwi API Class PHP: Версия 1.2 от 26.05.2018
Похожее в блоге
Shnapik
Вебмастер с опытом ищет приют! Возьмите меня, а то меня рвут!
76 комментариев
Подскажите метод определения платежной системы банковской карты.
Если вы про перевод средств, то вот номера:
Всё есть в документации, здесь же (в классе), собраны лишь методы для удобно работы с ними, чтобы вам не писать постоянно одно и тоже, а можно лишь подключить его. В остальном всё как в документации работает.
Я имею в виду в класс добавить метод определения банковской карты (1963 VISA / 21013 MasterCard / 31652 МИР)
Необходимо получить ответ как в документации:
<
«code»: <
«value»: «0»,
«_name»: «NORMAL»
>,
«data»: null,
«message»: «1963»,
«messages»: null
>
Все методы из класса в правильном ответе получают то же, что и в документации. Если речь об этом, если нет, то немного не понимаю что конкретно нужно.
Какой метод из класса используете вы?
Данного метода в вашем классе нет.
В документации используются другие заголовки и хост:
POST /card/detect.action HTTP/1.1
Host: qiwi.com
Accept: application/json
Content-Type: application/x-www-form-urlencoded
Cache-Control: no-cache
cardNumber=4256********1231
Здесь будет другой запрос cURL.
Пробовал дописать метод, но он не работает:
Здравствуйте. Такая же проблема. Как решили вопрос с определением провайдера перед отправкой средств?
Дмитрий, понять какой метод используется, точнее параметр (его id), для метода sendMoneyToProvider. Можно извне, например при post запросе в селекте выбора карты (где value будет иметь идентификатор провайдера).
Заголовки же все те же используются:
Понять верна ли карта или нет, через данный класс не получится. Можно лишь это понять будет во время перевода, например когда мы отправляем средства и нам выдает ошибку. Вы можете написать свои функции с проверкой «правильно ли введены данные», например по длине символов.
При попытке передать деньги выводится ошибка
Array ( [message] => Json validation error List((obj.paymentMethod.accountId,List(ValidationError(List(error.expected.jsstring),WrappedArray()))), (obj.sum.currency,List(ValidationError(List(error.expected.jsstring),WrappedArray()))), (obj.id,List(ValidationError(List(error.expected.jsstring),WrappedArray())))) )
Другие методы класса тоже не работает
Метод перевода средств исправлен в примере, теперь всё работает как надо. В статье и на гитхабе новые примеры уже указаны Спасибо:)
постоянно выбивает «Техническая ошибка»
При каких обстоятельствах? Какой метод используется? Как используется, что подключается кроме данного скрипта, как он подключается. Не хватает немного вот этой информации.
Пытаюсь перевести с Qiwi на Qiwi методом «sendMoneyToQiwi», в итоге когда делаю запрос выбивает «Техническая ошибка под кодом 300», подключается с помощью «require_once ‘Qiwi.php’;», без проблем работает «getBalance()», а вот перевод выбивает постоянно ошибку, уже какой день пробую а толку 0, хотя токен у меня разрешен на перевод без СМС
Код всего файла можно посмотреть?
Я не про код класса, он по идее остается неизменным. Я про код файла где подключается данный класс и в котором используются методы.
Как я подключался к QIWI
Зачем мне это было нужно?
Проект настойчиво требовал подключения удобных платежных систем. Да, есть webmoney, но не у всех. Да, есть moneybookers для карточек, но слишком долог бюрократический процесс.
Было принято решение принимать платежи через QIWI, во-первых потому что их автоматы есть практически везде, а во-вторых (тссс, большой секрет!) они готовят запуск системы прямых платежей со счета сотового оператора, без всяких дурацких СМС и девяностодевятипроцентных комиссий.
Ну, а поскольку запрашивать вручную у платежной системы реестры и вносить данные в бухгалтерию и на сайт – вчерашний день, был выбран полностью автоматический вариант подключения с использованием протокола SOAP.
Сказано – сделано!
Для сайта был взят вполне заурядный VDS, на котором собран вполне заурядный же серверный набор – nginx спереди, Apache позади.
Основа в виде некоей CMS у меня уже была, в том числе в ней был реализован и модуль личных счетов пользователей с подключаемыми модулями платежных систем.
Для работы с SOAP проще всего взять с гуглокода класс nuSOAP (http://code.google.com/p/nusoap-for-php5/).
Немногим сложнее и код для приема от платежной системы информации об изменении статуса (привожу сразу в окончательном виде):
$server = new nusoap_server;
$server->register(‘updateBill’);
$server->service($HTTP_RAW_POST_DATA);
// восстанавливаю информацию о внутренней транзакции
$transaction = TPTransactions::getTransactionByID(intval($txn));
if ( empty($transaction) )
return 300;
case 50:
// Bill created
return 0;
break;
case 60:
// Счет оплачен пользователем – завершаем транзакцию
TPAccount::proceedTransaction($transaction);
return 0;
break;
default:
// Что-то случилось, счет не оплачен, транзакцию нужно отменить
TPAccount::cancelTransaction($transaction);
return 0;
break;
Сюрприз первый. nuSOAP.
Вот вроде бы код написан, проверен на локальном сервере, пора познакомить мой PHP с благородной JAVA со стороны QIWI.
Первая неожиданность возникает мгновенно – nuSOAP при первой же попытке создать тестовый платеж озадачивает сообщением «Response not of type text/xml». Да, никак не ожидали создатели nuSOAP, что одна российская платежная система решит, что SOAP – это «application/soap+xml». Поправим их – достаточно несложно найти и закомментировать соответствующие проверки внутри кода nuSOAP.
И вот торжество – тестовый платеж создан, его видно в QIWI, настала пора принять от него ответ об успешной оплате.
Настройка nginx. Ошибка 411.
Однако меня ждет неприятный сюрприз. При попытке проверить работу веб-сервиса магазина, мой сервер неожиданно отвечает ошибкой 411 – Length required.
Ответ поддержки QIWI все прояснил:
«Здравствуйте. Наш сервис посылает chunked-запросы без указания content-length. Думаю у вашего веб-сервера должны быть настройки для обработки таких запросов.»
Для меня так и осталось навсегда загадкой, что мешает QIWI все-таки указывать Content-length, однако теперь многое стало понято. nginx не воспринимает chuncked запросы, сразу отвечая на них ошибкой…
Идем на сервер и за работу!
Скачиваем модуль NginxHttpChunkinModule, кладем его, распаковав, к примеру в /root/chunkin. Взять его можно здесь: http://wiki.nginx.org/NginxHttpChunkinModule, там же есть и инструкции по установке
Ничего сложного в установке нет, покажу на примере FreeBSD и nginx 0.7.64
Затем вносим в конфиг nginx (обычно это /usr/local/etc/nginx/nginx.conf) в секцию http параметр
и перезапускаем nginx
Еще один сюрприз – ошибка 501
И что вы думаете? Все заработало? Нет, конечно же.
Следующей напастью стала ошибка 501 Method Not Implemented. Ее причину удалось локализовать достаточно быстро, посмотрев логи сервера. Несмотря на то, что я прописал в интерфейсе QIWI адрес своего вебсервиса /account/result/qiwi.html, клиент QIWI упорно бился в закрытую дверь – он пытался делать запрос на несуществующий адрес /account/result/qiwi/
Что стало причиной такого поведения – узнать не удалось, однако одно правило mod_rewrite спасло ситуацию. Запрос стал приходить на нужный мне адрес. А затем поддержка QIWI оперативно решила эту проблему на своей стороне.
Последняя и самая страшная неожиданность
Ну и теперь, когда вроде бы уже все готово, QIWI подготовил мне еще один сюрприз. При попытке тестирования веб-сервиса магазина из интерфейса QIWI я неизменно получал сообщение «При запросе произошла ошибка: error in msg parsing: xml was empty, didn’t parse!»
На самом деле это хороший знак – значит nuSOAP работает, и даже отдает правильный, с точки зрения QIWI SOAP-ответ на запрос. Вот только никаких данных от QIWI он не видит…
Сказать, что проблему удалось быстро – не могу. Однако она все-таки решилась. Итак:
Идем в исходники модуля NginxHttpChunkinModule, файл ngx_http_chunckin_filter_module.c и комментируем следующие строчки:
r->headers_in.transfer_encoding->value.len = 0;
r->headers_in.transfer_encoding->value.data = (u_char*) «»;
ngx_http_chunkin_clear_transfer_encoding(r);
Глубоко разбираться в коде не было времени, так что можно считать это грубым, но действенным хаком.
Снова пересобираем nginx, и – вуаля!
Неожиданность совсем последняя
Создаю у себя транзакцию, вижу ее номер. Иду в личный кабинет QIWI и пытаюсь ей вручную задать статус «Оплачено». Тестовый скрипт QIWI добросовестно показывает мне 0 (нуль), но ничего не происходит…
Не буду утомлять читателей описание процесса поиска этого глюка. Скажу лишь, что тестовый скрипт всегда выдает нуль, независимо от ответа Вашего сервера, это «особенность системы (с) поддержка QIWI», а вот учесть тот факт, что написанная на Java-е клиентская часть платежной системы почему-то считает своим долгом передать хэш Вашего пароля в верхнем регистре – нужно обязательно.
Все работает, сайт запущен, получен бесценный опыт, которым я, в свою очередь, с удовольствием готов делиться с хабраюзерами (кстати, встречайте — это мой первый пост на Хабре!) и хабрачитателями.
Заранее спасибо, надеюсь, что моя статья поможет кому-то сэкономить хотя бы несколько минут драгоценного времени!
P.S. Ссылку на проект мог бы дать — да боюсь хабраэффекта. Может быть потом, в соответствующем блоге, когда буду уверен, что сервер выдержит…
UPD. Перенес в блог «Платежные системы»
QIWI и новый протокол REST в примерах
Приветствую.
Я являюсь давним читателем хабра и часто нахожу тут ответы на свои вопросы. Но вот так случилось, что ответа обнаружить не получилось. Причём нигде.
А задача была следующая. Реализовать новый (REST) протокол для системы QIWI. Мне пришлось потратить несколько дней, чтобы найти верное решение с помощью проб, ошибок, общений с менеджером и командой поддержки, т.к. примеров нигде нет, хотя задача не такая уж и сложная.
В данном сообщении я хочу поделиться теми примерами, которых мне так не хватало. Надеюсь, что это поможет кому-то.
Сразу скажу, что я не буду расписывать, разжевывать и объяснять подробно. Будет только основное, которое считаю необходимым. Всё же у каждого свои предпочтения и цели.
Для начала вам нужно зарегистрировать свой магазин http://ishopnew.qiwi.ru/
После регистрации в разделе Способы подключения вы найдёт пункт Новый протокол. Там можно скачать описание API нового протокола.
Для отправки запросов я использовал cURL.
Вот как это было:
Думаю тут всё просто и понятно.
Опишу отдельно для каждой операции.
1) Выставление счета пользователю
С параметрами всё понятно.
2) Запрос статуса счета
Если счёт не был оплачен после выставления, нам нужно проверить его статус. Возможно система задержала ответ или пользователь решил оплатить его чуть позже, в таком случае можно использовать cron.
3) Переадресация для оплаты счета
После успешного выставления счёта нужно перенаправить пользователя на страницу оплаты. Здесь cURL не используется, просто редирект.
4) Отмена неоплаченного выставленного счета
Используется для отмены выставленного счёта. Если вы выставили счёт, но он не оплачен, система будет высылать на адрес, указанный в настройках магазина, POST запросы на подтверждение статуса счёта. Если вы не ответите, то в итоге придёт письмо на email, указанный в настройках магазина.
5) Возврат средств по оплаченному счету
Вы можете потребовать вернуть оплаченные средства.
6) Проверка статуса возврата
Так же нужно проверять статус возврата по запросу, описанному выше.
Ответ сервера подробно описан в документации.
И конечно отдельное негодование хочется выразить по поводу тестирования. Система QIWI не имеет тестового режима или тестовой площадки, поэтому вам придётся использовать свой кошелёк и проводить платежи, к примеру, по 10 копеек.
Надеюсь, данным сообщением я хоть немного помог тем, кто собирается использовать новый протокол в своём проекте. Ведь он обещает возможность получать оплату со всех стран, где есть QIWI.