• Сверка платежей
Поставщику услуг раз в сутки отправляется на email(указанный при подключении) реестр платежей в формате .csv.
Формат файла:
OrderId;PaymentId;ServiceId;Account;Amount;OrderDate;
11;7891123;223;4589687;45.50;2010-05-02T14:05:30;
12;4139874;497;3257879;5.00;2010-05-02T20:05:30;
14;5478877;544;1121458;15.00;2010-05-02T21:08:30;
• Цифровая подпись
Для подписи запроса вы должны использовать все тело запроса с пустым тегом <Sign></Sign>:
Запрос:
<Request>
<DateTime>yyyy-MM-ddTHH:mm:ss</DateTime>
<Sign></Sign>
<Check>
<ServiceId>int</ServiceId>
<Account>string</Account>
</Check>
</Request>
Подпись: RSA1024(SHA1(Запрос))
Для проверки подписи используется аналогичная процедура:
Ответ:
<Response>
<StatusCode>int</StatusCode>
<StatusDetail>string</StatusDetail>
<DateTime>yyyy-MM-ddTHH:mm:ss</DateTime>
<Sign></Sign>
</Response>
• Схемы оплаты
• Прямое пополнение
1 Проверка возможности платежа(проверка абонента)
<Request>
<DateTime>2010-09-01T12:00:00</DateTime>
<Sign>94C8682CABCF1D…</Sign>
<Check>
<ServiceId>100</ServiceId>
<Account>12345678</Account>
</Check>
</Request>
<Response>
<StatusCode>0</StatusCode>
<StatusDetail>OK</StatusDetail>
<DateTime>2010-09-01T12:00:05</DateTime>
<Sign>47EDE8324D05CC1…</Sign>
<AccountInfo>
<Name>Иванов А.А.</Name>
<Address>ул. Садовая 5, кв. 16</Address>
<Balance>125.00</Balance>
</AccountInfo>
</Response>
Если проверка выполнена успешно переходим на шаг 2
2 Создание заказа
<Request>
<DateTime>2010-09-01T12:00:10</DateTime>
<Sign>2EE9485D8747963E…</Sign>
<Payment>
<ServiceId>100</ServiceId>
<OrderId>11</OrderId>
<Account>12345678</Account>
<Amount>25.00</Amount>
</Payment>
</Request>
<Response>
<StatusCode>0</StatusCode>
<StatusDetail>Order Created</StatusDetail>
<DateTime>2010-09-01T12:00:15</DateTime>
<Sign>D3479BB615EFF…</Sign>
<PaymentId>145</PaymentId>
</Response>
В случае успеха переходим на подтверждение платежа.
3 Подтверждение заказа
<Request>
<DateTime>2010-09-01T12:00:20</DateTime>
<Sign>615EFFD1D9E02BD…</Sign>
<Confirm>
<PaymentId>145</PaymentId>
</Confirm>
</Request>
<Response>
<StatusCode>0</StatusCode>
<StatusDetail>Payment Confirmed</StatusDetail>
<DateTime>2010-09-01T12:00:25</DateTime>
<Sign>E4E54DD77C157F…</Sign>
<OrderDate>2010-09-01T12:00:25</OrderDate>
</Response>
При подтверждении происходит списание средств со счета партнера. Если во время подтверждения произошол timeout – подтверждение может повторится, при этом должно возвращатся то же, что и в первый раз(OrderDate – при этом не изменяется).
• Офлайновые платежи
• Формат данных
Информацию о своих абонентах (если такая имеется) провайдер должен передавать в следующем формате:
<Clients>
<Client>
<Account>string</Account>
<AccountInfo>
<Name>string</Name>
<Address>string</ Address >
…
</AccountInfo>
</Client>
…
</ Clients>
Account – параметр, по которому осуществляется поиск в базе абонентов;
AссountInfo – любая информация о пользователе, необходимая, например, для вывода на терминале
Файл именуется как clients-304.xml, где 304 – номер сервиса (услуги), который сообщается провайдеру при заведении сервиса в системе.
• Дополнительные параметры
• Банковские реквизиты
Дополнительный параметр в операции Check. Возвращается провайдером, когда платежи на один сервис имеют разные банковские реквизиты.
<BankingDetails>
<Payee>
<Id>ЕГРПОУ или ИНН получателя</Id>
<Name>Название или имя получателя</Name>
<Bank>
<Name>Название банка получателя</Name>
<Mfo>МФО получателя</Mfo>
<Account>счет получателя</Account>
</Bank>
</Payee>
<Payer>
<Id>ЕГРПОУ или ИНН плательщика</Id>
<Name>Название или имя плательщика</Name>
<Bank>
<Name>Название банка плательщика</Name>
<Mfo>МФО плательщика</Mfo>
<Account>счет плательщика</Account>
</Bank>
</Payer>
<Narrative>
<Name>Назначение платежа в формате точно из договора</Name>
<Vat>20</Vat> <!--НДС, если не берется то 0-->
</Narrative>
</BankingDetails>
• Оригинальный номер сервиса
Дополнительный параметр в операции Check, возвращается, если для данного пользователь сервис пополнения отличный от того, который указан в запросе(можно указывать только те сервиса, которые заведены у нас в системе). Это бывает необходимо в ситуациях когда например в терминале сервис один, а у нас в системе для каждого города или филиала заведен свой(разные договора, банковские реквизиты). В этом случае операция покупки пройдет с новым ServiceId.
<OriginalServiceId>int</OriginalServiceId>
Пример:
<Request>
<DateTime>2010-09-01T12:00:00</DateTime>
<Sign>94C8682CABCF1D…</Sign>
<Check>
<ServiceId>100</ServiceId>
<Account>12345678</Account>
</Check>
</Request>
<Response>
<StatusCode>0</StatusCode>
<StatusDetail>OK</StatusDetail>
<DateTime>2010-09-01T12:00:05</DateTime>
<Sign>47EDE8324D05CC1…</Sign>
<AccountInfo>
<Name>Иванов А.А.</Name>
<Address>ул. Садовая 5, кв. 16</Address>
<Balance>125.00</Balance>
</AccountInfo>
<OriginalServiceId>101</OriginalServiceId>
</Response>
• Дополнение A
• Создание сертификата
openssl genrsa -out provider.ppk 1024
openssl req -new -key provider.ppk -out provider.req
openssl ca -in provider.req -out provider.cer
openssl x509 -req -days 730 -in provider.req -signkey provider.ppk -out provider.cer
При создании сертификата подписи используется CN=ProviderSign-ProviderName, где ProviderName – название провайдера латинскими буквами (например, CN=ProviderSign-TopNet)
• Подпись данных
Пример подписи на C#:
string path = "Provider-Test.pfx";
X509Certificate2 cert = new X509Certificate2(path,"test");
RSACryptoServiceProvider rsa = (RSACryptoServiceProvider)cert.PrivateKey;
byte[] signature = rsa.SignData(Encoding.UTF8.GetBytes(data), new SHA1CryptoServiceProvider());
string result = Utilities.BytesToHex(signature);
• Тестовый хост
Перед боевым запуском, Вы должны пройти тестирование на странице:
http://easysoft.com.ua/ProviderProtocolTest• Авторизационные данные на стороне провайдера
Провайдер должен заранее проинформировать о том, какого типа авторизация предусмотрена на их сервере (сертификаты, логин и пароль и т.д.)
Просмотр сообщений
