Ограничения контракта

• Card-on-file. save_payment_method и customer_reference не входят в действующий клиентский контракт — хранение карты включается отдельным согласованием возможностей.
• Подписки. Публичное создание и управление подписками пока не включено в онбординг: пригодный mandate_id наружу не выдаётся.
• Кошельки. Схема payload и сама возможность кошельковых операций согласуются отдельно.
• Прямой приём карт. H2H в боевом контуре запрещён без письменного согласования PCI и compliance.
• Возвраты и раздельный capture. Зависят от возможностей канала; отсутствие возможности возвращается как 422 capability_not_supported.

• Отдельный ключ на каждое приложение или интеграционный сервис.
• secret_key хранится только в серверном secret manager. Не в URL, не во фронтенде, не в мобильном бандле, не в репозитории, не в тикетах и не в логах.
• При утечке создаётся новый ключ, выполняется переход с перекрытием, старый отзывается.
• Если для ключа настроен CIDR-allowlist, запросы должны исходить с согласованных статических публичных адресов — иначе 403.
• Ключ и клиент могут быть заморожены; в этом случае операции отклоняются с 403 до снятия заморозки.

Реальное имя провайдера, его merchant ID и сырой payload провайдера наружу не передаются. Возможности канала описаны нейтрально — ровно затем, чтобы интеграция мерчанта не ломалась при смене провайдера.