Використовуйте бренд для обміну повідомленнями, що належить обліковому запису
Використовуйте активований обліковий запис API, підключаючись через HTTPS із дозволеної вихідної IP-адреси. Підтримується автентифікація Basic і Bearer. Ідентифікатор бренду має належати цьому обліковому запису. Зберігайте токени постачальника, ідентифікаційні дані бренду та отримані звіти конфіденційними.
Використовуйте наявний результат постачальника
Використовуйте PUT, щоб пов’язати наявний результат перевірки від підтримуваного постачальника зі своїм брендом. Це не замовляє нову перевірку. Отримайте правильний ідентифікатор транзакції постачальника та, за потреби, токен підтвердження безпосередньо в цього постачальника й переконайтеся, що звіт стосується того самого суб’єкта господарювання.
AUTHPLUS не підтримує цей процес імпорту. Правила зіставлення даних конкретного постачальника залишаються чинними; запит на імпорт не скасовує їх і не гарантує відповідності вимогам для кожного сценарію використання кампанії.
Підготуйтеся до імпорту
| Поле | Значення |
|---|---|
| evpId | Ідентифікатор підтримуваного постачальника, 1–10 символів. |
| vettingId | Справжній ідентифікатор транзакції перевірки в постачальника, до 255 символів. Не підставляйте замість нього ідентифікатор бренду й не вигадуйте ідентифікатор. |
| vettingToken | Токен підтвердження, якщо його вимагає постачальник, до 65535 символів. Зберігайте його в таємниці й не передавайте, якщо постачальник його не вимагає. |
Створіть vetting-import.json, використовуючи фактичні значення постачальника. Не надсилайте поля оцінки, статусу чи часової позначки, призначені лише для відповіді, наче вони можуть змінити результат.
Імпортуйте результат один раз
curl --silent --show-error --fail-with-body --user "$API_USER:$API_PASSWORD" \
--request PUT \
--header 'Content-Type: application/json' \
--header "Idempotency-Key: $IDEMPOTENCY_KEY" \
--data-binary @vetting-import.json \
"https://api.multitel.net/tcr/v2/brand/$BRAND_ID/externalVetting"Ознайомтеся з наявними нарахуваннями
Цей проксі не реєструє щойно імпортований результат як нове платне замовлення. Це не скасовує раніше замовлену перевірку: якщо для того самого vettingId уже є замовлення, яке очікує на результат або списання коштів, імпорт результату ACTIVE чи FAILED може спричинити списання збереженої для нього суми збору. У цій гілці синхронізації кошти за запис, за який їх уже списано, повторно не списуються.
Відстежуйте фактичний результат
Успішна відповідь HTTP може містити запис перевірки, що ще очікує на завершення. Збережіть його vettingId і перевірте vettingStatus, причини, оцінку та дати початку й завершення дії, якщо ці дані доступні. PENDING і UNSCORE потребують подальшого відстеження; ACTIVE, FAILED і EXPIRED описують різні результати. Саме лише прийняття запиту на рівні HTTP не підтверджує сприятливої оцінки чи відповідності вимогам кампанії.
Використовуйте статус зовнішньої перевірки для відстеження запису. Зчитування чи імпорт остаточного результату може спричинити списання коштів за попереднє платне замовлення; це не обов’язково відбувається без списання вже наявної несплаченої суми.
Повторіть той самий запланований запит
Використовуйте один Idempotency-Key для кожної запланованої операції та зберігайте точні метод, шлях, параметри запиту й байти тіла. Ключі можуть містити 1–128 друкованих символів ASCII без пробілів. Дублікат запиту, який ще виконується, може повернути 409 із Retry-After. Для завершених запитів повторно повертається збережена відповідь, зокрема помилки. Дотримуйтеся обмежень частоти запитів.
Після збою передавання даних може повертатися кешована відповідь 502. Кешована відповідь 500 із requestId може означати, що реєстр прийняв операцію, але локальне збереження даних або нарахування чи списання коштів завершилося помилкою. Збережіть ідентифікатор запиту, перевірте поточні записи й узгодьте їх зі службою підтримки, перш ніж використовувати новий ключ. Не вважайте, що помилка означає відсутність замовлення.