Прийняти платіж - документація fondy

Попередня ↔ Наступна

Статус обробки замовлення. Може містити наступні значення:
created - замовлення був створений, але клієнт ще не вніс платіжні реквізити; необхідно продовжувати опитувати статус замовлення
processing - замовлення все ще знаходиться в процесі обробки платіжним шлюзом; необхідно продовжувати опитувати статус замовлення
declined - замовлення відхилений платіжним шлюзом FONDY, зовнішньої платіжною системою або банком-еквайром
approved - замовлення успішно здійснений, кошти заблоковані на рахунку платника і незабаром будуть зараховані Мерчант; мерчант може надавати послугу або "відвантажувати" товар
expired - час життя замовлення, вказане в параметрі lifetime. минув.
reversed - раніше успішна транзакція була повністю або частково скасована. В такому випадку параметр reversal_amount має не нульове значення

Статус обробки запиту. Якщо виникла помилка при валідації переданих параметрів, то повертається failure. інакше success

Формування підпису запиту і відповіді (параметр signature)

Підпис формується шляхом застосування функції SHA1 до рядка, що складається з пароля мерчанта і всіх параметрів, пріконкатенірованних до нього в алфавітному порядку і розділених символом вертикальної риски |

Запит від мерчанта:

рядок, використана для формування підпису:

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

Приклад коду перевірки підпису на сторінках зазначених в параметрах response_url або server_callback_url з використанням PHP SDK:

Допоміжний файл з прикладами функцій для роботи з підписом Signature.php

Перевірка підпису за допомогою класу Signature

Рішення проблем з генерацією та валідація параметра signature

Існує дві типових ситуації, коли виникає помилка перевірки параметра signature.

Якщо запит на купівлю / рекурентное платіж / реверс / статусу або будь-який інший запит з параметром signature відправлений на API Fondy, і повернувся відповідь: Invalid signature.
Якщо від сервера Fondy на server_callback_url або response_url повернувся POST відповідь, але при спробі сформувати підпис і порівняти її з параметром signature з POST відповіді, підписи не збігаються

Розглянемо обидва випадки:

Якщо запит відправлено на API Fondy, і відповідь повернувся виду "Invalid signature signature:` 6bd069be8a6e2f2bbe176df00ba63cc681ca38aa`; response_signature_string: `********** | 125 | USD | 1396424 | demo order 789 | Demo123456`", виконайте наступні перевірки:

перевірте, що ви використовували коректний пароль з Технічних налаштувань мерчанта в Мерчант-порталі:

якщо запит містить кириличні або інші не латинські літери, то він відправлений у кодірорке UTF-8

переконайтеся, що параметр із значенням 0 не наводиться вашим мовою програмування до порожнього значенням

Залогуйтесь в програмному коді рядок, до якої ви застосовуєте SHA1 під час формування параметра signature. Порівняйте його з рядком, яка повернулася в тексті помилки (відзначено червоним кольором): "Invalid signature signature:` 6bd069be8a6e2f2bbe176df00ba63cc681ca38aa`; response_signature_string: `********** | 125 | USD | 1396424 | demo order 789 | Demo123456` ". Врахуйте, що в тексті помилки фраза-пароль мерчанта буде замаскована знаком *

перевірте, передаєте ви в запиті до API порожні параметри. Якщо так, то в самому рядку, яка бере участь в підпису, символ роздільник | для кожного такого порожнього параметра включати не потрібно

якщо ви розробляєте на мові програмування PHP, скористайтеся прикладом функції getSignature:

переконайтеся, що результат функції SHA1 приведений до нижнього регістру. Правильно. 6bd069be8a6e2f2bbe176df00ba63cc681ca38aa. Чи не правильно. 6BD069BE8A6E2F2BBE176DF00BA63CC681CA38AA

переконайтеся, що параметр signature не включений вами в розрахунок підпису

переконайтеся, що якщо ви використовуєте точку API / api / recurring. то вами в підпис включені тільки необхідні параметри

Якщо від сервера Fondy на сторінки, зазначені в параметрах server_callback_url або response_url повернувся POST відповідь, але при спробі сформувати підпис і порівняти її з параметром signature в POST відповіді, підписи не збігаються

Приклад відповіді від Fondy (JSON):

Щоб діагностувати причину розбіжності підпису, виконайте наступні дії:

переконайтеся, що параметр із значенням 0 не наводиться вашим мовою програмування до порожнього значенням
переконайтеся, що параметри response_signature_string і signature не включені вами в розрахунок підпису (параметр response_signature_string повертається тільки якщо мерчант знаходиться в тестовому режимі і містить підказку, як була сформована підпис у відповідь)
якщо запит містить кириличні або інші не латинські літери, то він відправлений у кодуванні UTF-8
Залогуйтесь в програмному коді рядок, до якої ви застосовуєте SHA1 під час формування параметра signature. Порівняйте його з рядком, яка повернулася в параметрі response_signature_string
перевірте, чи повернулися у відповіді порожні параметри. Якщо так, то в самому рядку, яка бере участь в підпису, символ роздільник | для кожного такого порожнього параметра включати не потрібно
якщо ви розробляєте на мові програмування PHP, скористайтеся функцією getSignature:
переконайтеся, що результат функції SHA1 приведений до нижнього регістру. Правильно. 6bd069be8a6e2f2bbe176df00ba63cc681ca38aa. Чи не правильно. 6BD069BE8A6E2F2BBE176DF00BA63CC681CA38AA

формування запиту

Запити на сервер FONDY можна відправляти 2-ма способами

Схема взаємодії B АПИ підтримує такі текстові формати запитів: HTML FORM, XML, JSON. Цей варіант зручно використовувати для:

В контексті запиту завжди повертається відповідь в тому ж форматі, що і запит. Тобто якщо запит був в форматі JSON, то і відповідь повернеться в форматі JSON. Відповідь на такий запит є проміжним і містить URL, на який необхідно перенаправити клієнта для введення реквізитів платежу.

Відправлення запиту по схемі взаємодії A гадки не мав проміжного відповіді в контексті запиту. Фінальний відповідь буде повернутий на URL мерчанта, вказаний в параметрах response_url і server_callback_url.