Разработчикам

SDK roadmap

SDK должен упрощать интеграцию, но не скрывать от разработчика платежные статусы, ошибки провайдера, idempotency и правила повторных попыток.

Описание

SDK roadmap показывает, какие библиотеки и примеры VPOS.am стоит выпускать после стабилизации API-контракта и webhook lifecycle.

Почему SDK выпускается после API-контракта

Если начать с SDK раньше стабильного контракта, библиотека быстро станет источником несовместимости. Сначала фиксируются статусы, ошибки, webhook payload, idempotency и правила авторизации.

После этого можно выпускать тонкие helper-библиотеки, которые ускоряют типовые действия, но не прячут важные детали платежного lifecycle.

Какие примеры приоритетны

Для бизнеса в Армении практичнее начинать с backend-примеров: PHP/Laravel для сайтов и CRM, Node.js для webhook handlers, Python/FastAPI для внутренних API и интеграционных сервисов.

Отдельные примеры нужны для WooCommerce, OpenCart и custom checkout, но они должны опираться на тот же server-side контракт.

Как сохранять прозрачность ошибок

SDK не должен превращать все ошибки в общий failed. Интегратору важно отличать validation error, provider timeout, duplicate idempotency key, rejected payment и pending status.

Такая детализация помогает правильно строить retries, показывать сообщения пользователю и не ломать CRM/ERP-процессы.

Частые вопросы

Почему сначала API contract, а потом SDK?

SDK должен повторять стабильный contract. Если статусы, ошибки и webhook payload еще меняются, библиотека быстро станет источником несовместимости для интеграторов.

Какие SDK и примеры стоит делать первыми?

Наиболее практичны PHP/Laravel для сайтов и CRM, Node.js для webhook verification и Python/FastAPI для внутренних API. CMS examples должны использовать тот же server-side contract.