Provider Postman

Provider → методи → Postman

Аргументи: лінк на документацію провайдера та/або шлях до файлу (PDF, OpenAPI/Swagger YAML/JSON, Postman collection, DOCX, HTML, MD…). Якщо нічого не передано — спитай.

Джерело правди — тільки документація провайдера (лінк/файл) і реальні відповіді провайдера. Не покладайся на локальні репозиторії: на іншому ПК їх може не бути. Якщо користувач сам попросить звірити з кодом — це окремий крок, не частина цього процесу.

Мова всіх описів — українська. Назви полів, ендпоінтів, заголовків — як у документації.

0. Підготовка

1. POSTMAN_API_KEY — зі змінної середовища або ./.env. Немає → попроси ключ у користувача (Postman → Settings → API Keys) і збережи в .env як POSTMAN_API_KEY=…. У ключа обмежений термін дії: 401 від Postman = ключ протух, попроси новий.
2. Хелпер: python3 <директорія цього skill-а>/postman_builder.py (команди workspaces, find, tree, build, sync, update, tests, verify; опис — у docstring). Статистика сесії — session_stats.py там само. Директорія skill-а — це «Base directory» з заголовка, з яким завантажився skill. Формат специфікації — spec.example.json там само.
3. Робоча директорія для опису: ./provider-docs/<provider>/ (від поточної директорії сесії). Проміжні файли (завантажені специфікації, чернетки spec) — у scratchpad.

1. Збір методів з документації

1. Відкрий лінк (WebFetch). Якщо сторінка рендериться JS-ом або контент неповний — через Chrome (skill claude-in-chrome) або пошукай машиночитну специфікацію: openapi.json/yaml, swagger, «Download OpenAPI», «Run in Postman», GitHub-репозиторій SDK/spec провайдера. Специфікація OpenAPI / Postman collection від провайдера — найкраще джерело, бери її, якщо є.

2. Файл від користувача — прочитай повністю (PDF — сторінками), це рівноцінне джерело до лінку.

3. Пройди навігацію документації (API reference, Guides) і знайди методи за категоріями:

   Категорія	Що шукати
   Автентифікація	тип (Bearer, Basic, HMAC-підпис, OAuth token), заголовки, як отримати токен, sandbox vs prod base URL
   Режими SMS / DMS	див. «SMS / DMS» нижче — обов'язково для кожного методу оплати
   3DS / без 3DS / external MPI	див. «3DS» нижче — обов'язково для кожного методу оплати
   Стандартна оплата	create payment / authorize / sale / charge, 3DS (redirect, challenge, callback), confirm
   Рекурентні	збереження картки/токена (tokenize, customer, payment method, mandate), MIT / off-session на токені провайдера
   MIT за scheme_id	див. «MIT за scheme_id» нижче — обов'язкова перевірка
   Статус / деталі	get payment / transaction / order, пошук за order id
   Capture (DMS)	повний і частковий, множинні capture, capture більшої суми (якщо дозволено)
   Void / Cancel (DMS)	скасування авторизації до capture, причини; чи можна void після capture (зазвичай ні)
   Refund	повний і частковий, множинні refund-и, статус refund-у; для SMS — єдиний спосіб повернення
   Apple Pay	(a) токен провайдера / зашифрований payment token → провайдер розшифровує; (b) розшифровані дані (DPAN / network token + cryptogram + ECI) — merchant decrypt, див. «Гаманці: розшифровані дані»
   Google Pay	(a) токен провайдера / encrypted paymentData; (b) розшифровані дані (CRYPTOGRAM_3DS і PAN_ONLY) — див. «Гаманці: розшифровані дані»
   Вебхуки / IPN	формат нотифікацій, підпис — лише описати, запити в Postman не створювати
   Тестові дані	тестові картки (успіх, decline, 3DS), тестові токени гаманців, test helpers

   SMS / DMS. SMS (Single Message) — авторизація і списання одним запитом (sale / purchase / auto capture), повернення лише через refund. DMS (Dual Message) — авторизація з блокуванням коштів (hold), потім окремий capture або void; після capture — тільки refund. Для провайдера з'ясуй:

   • як обирається режим: окремі ендпоінти (/sale vs /authorize + /capture), параметр у запиті (capture_method=automatic|manual, intent=CAPTURE|AUTHORIZE, auto_capture, type=SALE|AUTH…) чи налаштування акаунта/MID (тоді в запиті режиму не видно — так і запиши);
   • термін життя авторизації, що відбувається після нього (auto-void / auto-capture);
   • частковий / множинний capture, void після часткового capture;
   • які статуси повертаються в кожному режимі (напр. requires_capture / authorized vs succeeded / captured);
   • чи підтримується кожен режим для recurring, Apple Pay, Google Pay (буває, що гаманці — лише SMS). Якщо документація не згадує DMS — запиши «DMS у документації не знайдено», не вигадуй capture/void.

   3DS. Три режими автентифікації власника картки — з'ясуй кожен:

   • 3DS провайдера (провайдер — 3DS Server): як увімкнути/примусити (three_ds: required, request_three_d_secure=any…); обов'язкові дані для 3DS2 — browser info (accept header, user agent, language, color depth, screen, time zone, java/js enabled, IP), return_url/notification_url, дані власника (email, billing address, phone); чи є 3DS Method (device fingerprint, methodURL, threeDSMethodData) і як повідомити його результат; як виглядає challenge (redirect URL, acsURL + creq, для 3DS1 — PaReq/MD), яким запитом завершується (complete / confirm / authorize after 3DS) або що фінальний статус приходить лише вебхуком; що повертається (ECI, CAVV, dsTransID, transStatus Y/A/N/U/C/R, liability shift); frictionless vs challenge; підтримка 3DS1 (якщо ще є) і 3DS2; тестові картки для frictionless, challenge, failed, attempted.
   • Без 3DS: як вимкнути (three_ds: skip, налаштування MID…), чи дозволено провайдером; винятки SCA (low value, TRA, MIT, whitelisting — поля exemption/sca_exemption), що буде при soft decline (коди 1A / 65, «authentication required») і як повторити з 3DS.
   • External MPI (3DS пройдено власним MPI мерчанта): чи підтримується; поля з результатами автентифікації — authentication_value/CAVV/AAV (формат, кодування), eci, ds_transaction_id (3DS2) / xid (3DS1), version, trans_status, acs_transaction_id, exemption, challenge_indicator; які з них обов'язкові для кожної версії та платіжної системи. Для гаманців: Apple Pay / Google Pay CRYPTOGRAM_3DS самі несуть cryptogram + ECI (3DS не потрібен); Google Pay PAN_ONLY зазвичай вимагає 3DS — перевір. Для recurring: MIT зазвичай без 3DS; перший CIT для збереження картки — з 3DS; перевір, чи провайдер приймає 3DS / external MPI дані на рекурентних. Не підтримується режим — запиши «не підтримується / не знайдено» із джерелом.

   MIT за scheme_id (обов'язкова перевірка). Мерчант сам зберігає картку (PAN у власному vault, network token, DPAN/MPAN гаманця) і ID транзакції платіжної системи з першого CIT (scheme id / network transaction id: Visa Transaction ID, Mastercard Trace ID / Financial Network Code…) і проводить наступні MIT через провайдера — у т.ч. якщо перший платіж ішов через іншого провайдера. З'ясуй:

   • звідки брати scheme id: поле у відповіді на initial / у статусі / у вебхуку (network_transaction_id, scheme_transaction_id, scheme_reference, trace_id, transaction_identifier…), для якого флоу воно повертається (CIT з 3DS, без 3DS, гаманці);
   • як передати в MIT: поле з попереднім scheme id (previous_network_transaction_id, mit_exemption[network_transaction_id], original_transaction_id, scheme_reference…) і stored-credential індикатори: ініціатор (merchant), тип MIT (recurring / unscheduled / installment, stored_credential_transaction_type), використання (first / subsequent), off_session / recurring_indicator; чи потрібен прапорець на першому CIT (first / setup);
   • джерело картки в MIT: PAN (зазвичай потребує PCI / дозволу на raw card data), network token (+ cryptogram чи без), DPAN/MPAN Apple Pay, Google Pay; чи потрібен CVV/3DS (зазвичай ні);
   • SMS / DMS для MIT, обмеження мереж, коди відмов (напр. «transaction not permitted»);
   • статус: публічно / закрита функція (джерело) / не підтримується / не знайдено — ті самі джерела й порядок пошуку, що для розшифрованих даних гаманців (включно зі старими папками колекції та питанням до користувача).

   Гаманці: розшифровані дані (обов'язкова перевірка). Мерчант сам розшифровує токен Apple Pay / Google Pay і передає провайдеру дані картки-токена. Шукай наполегливо — такі можливості часто закриті (вмикаються для акаунта) і не описані в публічному API reference:

   1. Публічна документація та специфікація: пошук за network_token, cryptogram, eci, electronic_commerce_indicator, dpan, tokenization_method, decrypted, merchant decryption, payment_data, onlinePaymentCryptogram, eciIndicator, authMethod, CRYPTOGRAM_3DS, PAN_ONLY, network token, wallet/apple_pay/google_pay у параметрах запиту оплати.
   2. Непублічні / суміжні джерела: support-статті і changelog провайдера, офіційні SDK на GitHub (назви полів у моделях запитів), сторінки «network tokens», «card-on-file / migration», «raw card data», наявні папки колекції провайдера в Postman (tree) і файли від користувача.
   3. Якщо в публічних джерелах немає — спитай користувача, чи є приватна документація / приклад запиту від провайдера (з акаунт-менеджером часто домовляються окремо). Для кожного гаманця зафіксуй статус: публічно / закрита функція (знайдено лише в непублічних джерелах — вказати джерело) / не підтримується (з посиланням) / не знайдено. Опиши маппінг полів розшифрованого токена на параметри провайдера:
   • Apple Pay (paymentData після розшифрування): applicationPrimaryAccountNumber → номер токена; applicationExpirationDate (YYMMDD) → місяць/рік; paymentData.onlinePaymentCryptogram → cryptogram; paymentData.eciIndicator → ECI (часто доповнити нулем до 2 символів); paymentDataType (3DSecure / EMV); deviceManufacturerIdentifier; тип токена (DPAN / MPAN) для recurring.
   • Google Pay (paymentMethodDetails): pan, expirationMonth, expirationYear, authMethod (CRYPTOGRAM_3DS → cryptogram + eciIndicator, як network token; PAN_ONLY → звичайна картка, часто з 3DS провайдера), messageExpiration. Для кожного підтримуваного варіанта також: SMS/DMS, recurring (MIT на network token / DPAN / MPAN).

   Для кожного методу збери: HTTP-метод і шлях, лінк на сторінку методу, обов'язкові та опційні параметри (тип, формат, обмеження), заголовки (idempotency, версія API, підпис), формат суми (мінорні одиниці / десяткові, zero-decimal валюти), приклад запиту і відповіді, статуси, коди помилок.

4. Чогось немає в документації (наприклад, void або decrypted Apple Pay) — так і запиши «у документації не знайдено» з переліком місць, де шукав. Не вигадуй ендпоінти й поля.

2. Локальний опис методів

Файл ./provider-docs/<provider>/methods.md (якщо вже є — онови, дата в шапці):

# <Provider> — API методи
Джерело: <лінк(и)> / <файл>. Зібрано: <YYYY-MM-DD>.

## Автентифікація та загальне
Base URL (sandbox / prod), auth, обов'язкові заголовки, idempotency, формат суми, версія API.

## Режими SMS / DMS
| | SMS | DMS |
|---|---|---|
| Як увімкнути | … | … |
| Статус після оплати | … | … |
| Capture / Void | — | повний/частковий/множинний; термін авторизації |
| Повернення | refund | void до capture, refund після |
| Card / Recurring / Apple Pay / Google Pay | ✅/❌ | ✅/❌ |

## 3DS
| | 3DS провайдера | Без 3DS | External MPI |
|---|---|---|---|
| Як увімкнути | … | … | … |
| Обов'язкові поля | browser info, return_url… | … | CAVV, ECI, dsTransID, version… |
| Потік / завершення | frictionless / challenge → … | — | — |
| Статуси | … | … | … |
| Card / Recurring / Apple Pay / Google Pay | ✅/❌ | ✅/❌ | ✅/❌ |
| Тестові картки | frictionless / challenge / fail | … | — |

## <Категорія>
### <Назва методу>
- **Запит:** `POST /path`
- **Документація:** <лінк на метод>
- **Призначення:** 1–2 речення.
- **Режим:** SMS / DMS / обидва (яким параметром); 3DS провайдера / без 3DS / external MPI (якими полями).
- **Параметри:** список `name` (тип, required/optional) — опис/допустимі значення.
- **Приклад запиту / відповіді:** короткі блоки коду.
- **Статуси / помилки:** ключові значення.
- **Примітки:** 3DS, обмеження, відмінності sandbox.

## MIT за scheme_id
| | Статус | Джерело | Поле scheme id у відповіді CIT | Поля в MIT | SMS / DMS |
|---|---|---|---|---|---|
| Card (PAN) | … | … | … | … | … |
| Network token | … | … | … | … | … |
| Apple Pay DPAN / MPAN | … | … | … | … | … |
| Google Pay | … | … | … | … | … |

Stored-credential індикатори (first / subsequent, recurring / unscheduled / installment): …

## Гаманці: розшифровані дані
| | Статус (публічно / закрита функція / не підтримується / не знайдено) | Джерело | Поля | SMS / DMS | Recurring |
|---|---|---|---|---|---|
| Apple Pay decrypted | … | … | … | … | … |
| Google Pay CRYPTOGRAM_3DS | … | … | … | … | … |
| Google Pay PAN_ONLY | … | … | … | … | … |

Маппінг полів розшифрованого токена → параметри запиту: …

## Не знайдено в документації
- …

Поруч збережи завантажені специфікації (openapi.json тощо), якщо вони були.

3. Колекція та версійна папка в Postman

1. postman_builder.py find <provider> — знайди колекцію провайдера та його оточення. Робочий простір — той, де лежить колекція. Для нової колекції: workspaces → покажи список і спитай користувача, куди створювати (якщо він не назвав сам). Обраний workspace запам'ятай для наступних разів.

2. tree <collection_uid> — подивись наявні папки та оточення, щоб зрозуміти, як провайдера тестували раніше (корисно для тестових даних), але не копіюй їх структуру наосліп.

3. Версія:

   • колекції немає → створюється колекція <provider> з папкою v1;
   • є тільки папки без версії → v2;
   • є vN → v(N+1). build рахує це сам ("version": null). Наявні папки не чіпай.

4. Структура всередині vN (порожні категорії пропускай, нумерація підпапок наскрізна):

   1. Card — Initial
   2. Card — Recurring — підпапки Provider token і Scheme ID (MIT)
   3. Status / Details
   4. Capture / Void / Refund
   5. Apple Pay (Provider token та Decrypted data — окремими запитами/флоу)
   6. Google Pay (так само)

   Всі варіанти — обов'язково. Для кожного методу оплати (Card initial, recurring, Apple Pay, Google Pay) створи кожну комбінацію, яку підтримує провайдер: {3DS провайдера | Non-3DS | External MPI} × {SMS | DMS}, для гаманців ще × {Provider token | Decrypted data}. Нічого не скорочуй і не замінюй приміткою «відрізняється одним параметром» — кожен варіант має бути готовим до запуску запитом.

   • Всередині методу — підпапка на режим 3DS (3DS (provider), Non-3DS, External MPI; для гаманців спершу Provider token / Decrypted data, далі режими 3DS, якщо вони там доречні). У підпапці — запити флоу; запит оплати двома варіантами: 1. Create Payment (3DS, SMS) і 1. Create Payment (3DS, DMS) (однаковий номер — це альтернативи одного кроку).
   • 3DS (provider): після оплати — усі кроки, які є в провайдера: 3DS Method, Complete 3DS / Confirm, отримання статусу. Browser info — у тілі запиту літералами (реалістичні значення).
   • Опис кожного варіанта: чим відрізняється (параметр/ендпоінт), очікуваний статус, яку тестову картку взято і який сценарій вона дає (frictionless / challenge / decline).
   • Scheme ID (MIT) створюється завжди (у Card — Recurring, а для гаманців — у Apple Pay / Google Pay → Recurring — Scheme ID):
     • флоу: 1. Initial CIT (…) зі stored-credential прапорцем first, що зберігає scheme id у змінну оточення (saves, напр. scheme_id), і 2. MIT by scheme_id (…), що його використовує; якщо провайдер повертає scheme id лише в статусі чи вебхуку — між ними Get Payment;
     • варіанти: кожне підтримуване джерело картки (PAN / network token / DPAN) × кожен тип MIT (recurring, unscheduled, installment — ті, що підтримує провайдер) × {SMS, DMS}; окремий запит «MIT за зовнішнім scheme_id» (scheme id від іншого провайдера — літерал-приклад);
     • статус «закрита функція» → суфікс [Private], в описі джерело параметрів і що функцію треба ввімкнути (PCI / raw card data тощо); «не знайдено» → як для гаманців (питання користувачу, інакше папка з описом без запитів).
   • Гаманці — Decrypted data створюється завжди для Apple Pay і Google Pay:
     • статус «публічно» → усі комбінації: Apple Pay decrypted × {SMS, DMS}; Google Pay CRYPTOGRAM_3DS × {SMS, DMS} і PAN_ONLY × {3DS провайдера, Non-3DS, External MPI (якщо можна)} × {SMS, DMS}; плюс recurring на збереженому токені, якщо підтримується;
     • статус «закрита функція» → ті самі запити, у назві суфікс [Private], в описі: звідки взято параметри, що функцію треба ввімкнути у провайдера, і маппінг полів із розшифрованого токена;
     • «не знайдено» → після відповіді користувача: є приклад/доки → як «закрита функція»; немає → папка без запитів з описом, де шукали і що відсутнє;
     • дані в тілі — реалістичний формат (DPAN 16 цифр, cryptogram base64 28 символів, ECI 05/07), явно позначені в описі як приклад: з тестовими ключами провайдера вони пройдуть лише якщо провайдер це дозволяє в sandbox.
   • Непідтримувані комбінації не створюй — перелічи їх в описі підпапки методу («DMS для Google Pay не підтримується — <лінк>»).
   • Режим задається тільки налаштуванням акаунта/MID → один запит і примітка про це.
   • У Capture / Void / Refund: capture і void позначені (DMS), в описі — void лише до capture, після нього — refund; частковий capture / refund — окремими запитами, якщо підтримуються. Скрипт підтримує вкладені папки довільної глибини (folders всередині папки в spec). Запити в підпапці нумеруй у порядку виконання флоу (1. …, 2. …). Допоміжні запити, яких немає в реальній інтеграції (test helpers, емуляція фронту), познач [Test helper] / [Frontend emulation] у назві.

4. Генерація запитів і environment

Склади spec (формат — spec.example.json) у scratchpad і запусти postman_builder.py build <spec> --dry, потім без --dry. Після створення впиши в spec collection_uid і version — далі правки тільки через update <spec> (оновлює на місці за назвами).

Доповнення наявної версії (користувач просить «доопиши / додай відсутнє» у вже створеній vN):

1. Візьми spec цієї версії (./provider-docs/<provider>/*_spec.json); якщо його немає — tree і відтвори структуру в spec (назви папок і запитів — точно як у Postman).
2. Звір вміст vN з поточними правилами skill-а (усі комбінації 3DS × SMS/DMS, Scheme ID (MIT), Decrypted data, [Private]-статуси, описи з джерелами) і допиши в spec відсутнє; зміни в описах наявних запитів — окремим частковим spec (лише змінені запити).
3. sync <spec> --dry → sync <spec> — створює відсутні папки/запити, оновлює описи папок, додає в оточення нові змінні (значення наявних не чіпає); далі update <частковий spec> для змінених запитів.
4. Онови methods.md (нові таблиці/статуси, кількість запитів) і verify. Наявні запити, які користувач міг правити вручну, не перезаписуй без потреби.

Правила:

• Документація в кожному запиті: поле docs (лінк на конкретний метод) — хелпер додає 📖 Документація: <лінк> в опис запиту; для підпапок — docs папки; для версійної папки — docs_url.
• Опис запиту: що робить, звідки беруться значення, обов'язкові/опційні поля, допустимі значення. Опційні поля, які зазвичай не шлють, — додай вимкненими (4-й елемент false).
• Auth — auth верхнього рівня spec: хелпер ставить його на версійну папку і явно в кожен запит з відповідним Auth Type (Bearer / Basic / API Key…), бо запит, створений через API без auth, Postman показує як «No Auth» і не успадковує від папки. Запит з іншою авторизацією — власне поле auth у spec (напр. {"type": "noauth"} для публічного ендпоінта). Підпис запиту (HMAC тощо) — pre-request скриптом на рівні папки.
• Environment <PROVIDER>_V<N>_SANDBOX — мінімальний:
  • base_url і ключі доступу (тип default, значення порожні — користувач вписує ключ у Current value, яке не синхронізується з командою; не копіюй ключі з інших оточень чи файлів скриптами). Тип secret не використовуй: Postman може перевести такі змінні у Vault і вимагати vault key, а порожня змінна дає запит без Authorization;
  • змінні, які скрипти зберігають з відповідей (saves: id клієнта, платежу, токена, NTID…);
  • id, згенеровані на початку флоу й потрібні кільком запитам (order id / idempotency base). Суми, валюта, картка, email, адреса, версія API, причини void/refund — літералами в запиті. Одноразові id, потрібні лише одному запиту, — pm.variables.set(...) у його pre-request.
• Тестові дані — з документації провайдера (тестові картки, тестові токени). Дані Apple/Google Pay з документації або явно позначені як приклад формату.
• Тести — обов'язково для кожного запиту (поле tests у spec; хелпер генерує pm.test(...), формат ключів — у docstring tests_script: status, max_time, json, one_of, exists, absent, type, match, equals_var, error, header, lines). Значення беруться лише з документації провайдера (статуси, поля, коди помилок) — не вигадуй:
  • позитивні: HTTP-код; очікуваний статус операції з урахуванням варіанта (SMS → фінальний / списаний, DMS → авторизований, 3DS → one_of фінального статусу та «потрібна дія» + наявність redirect-URL); відлуння суми, валюти, режиму capture, order id (equals_var); наявність id, які зберігаються в saves, і scheme id для MIT-флоу; формат id (match); для Capture / Void / Refund — новий статус і суми (captured / refunded amount);
  • негативні — окремі запити в підпапці Negative кожного розділу (назва N. … → <очікувана помилка>): тестові картки з відмовами (decline, insufficient funds, 3DS failed), відсутній або невалідний ключ (власний auth), обов'язкове поле відсутнє, capture для SMS-платежу, void після capture, refund більший за суму, повтор з тим самим idempotency-ключем і іншим тілом — тільки ті, що описані в документації, з її кодами (status 4xx + error);
  • [Private]-запити: status дозволяє і успіх, і помилку «функцію не ввімкнено» (якщо її код відомий), в описі — що саме означає кожен результат;
  • спільні перевірки (час відповіді, JSON, логування помилки) — folder_test на версійній папці; HTTP-код у folder_test не перевіряй (інакше впадуть негативні тести) — лише в tests запиту. Додати / оновити тести у вже створених запитах — tests <spec>: замінює лише згенерований блок тестів (після маркера), не чіпаючи тіло запиту, saves і ручні правки користувача; перед генерацією візьми фактичні параметри запитів із Postman (GET /collections/<uid>), а не лише зі spec — користувач міг їх змінити. Нові негативні запити — через sync. Спільний тест версійної папки, що перевіряє HTTP-код, виправ (PUT папки з новим events). Запити й підпапки впорядковуй так, щоб Collection Runner / newman проходив флоу згори донизу (спільні id з попередніх кроків).
• Скрипти: saves зберігає значення тільки при 2xx; перший запит флоу генерує спільні id через pm.variables.replaceIn('{{$guid}}').

5. Перевірка

1. postman_builder.py verify <spec> — у запитах не має бути змінних, яких немає в оточенні (крім локальних pm.variables), і в оточенні — зайвих змінних.
2. tree <collection_uid> — структура на місці.
3. Тести запуском: якщо користувач вписав sandbox-ключі (переконайся, що ключ тестовий — напр. sk_test_, а не бойовий) і дозволив — експортуй колекцію й оточення через Postman API (GET /collections/<uid>, GET /environments/<uid>) у scratchpad і прожени версійну папку: npx -y newman run collection.json -e env.json --folder vN --env-var secret_key=<ключ від користувача> (ключ не записуй у файли; бойовими ключами не запускай). Виправ запити й тести за реальними відповідями; розбіжності з документацією фіксуй у methods.md. Без ключів — лише verify і підсумок, що тести не запускались.

6. Звіт користувачу

Статистика використання Claude — обов'язкова частина звіту. Перед звітом запусти python3 <директорія цього skill-а>/session_stats.py (з робочої директорії сесії) і встав отриману таблицю як розділ «Статистика роботи Claude» без змін: час (загальний / активний), модель, кількість викликів, токени (output, input, запис у кеш, читання з кешу), інструменти, кількість запусків build/update. Вартість у доларах не вигадуй — порадь /cost або /usage.

Коротко: джерела, скільки методів знайдено по категоріях, матриця підтримки (SMS/DMS × 3DS / без 3DS / external MPI по кожному методу оплати; кількість тестів (позитивних / негативних) і результат прогону, якщо він був; окремо — статус MIT за scheme_id і розшифрованих даних Apple Pay / Google Pay з джерелами) і скільки варіантів запитів створено, чого немає в документації, шлях до methods.md, назва колекції/папки/оточення, що треба заповнити (ключі), що не перевірено запуском.