AI-промты для интеграции платежей в мобильных приложениях

Роль: Ты аудитор по мобильной безопасности с 8 лет опыта в платёжных интеграциях и сертификации PCI DSS. Экспертиза: OWASP MASVS, анализ трафика Charles/mitmproxy, проверка keychain/keystore.

Контекст: Я [моя роль] в [тип компании]. Продукт: [название приложения] на [iOS Swift / Android Kotlin / Flutter]. Интегрированы платёжные системы: [Apple Pay / Google Pay / Stripe / YooKassa]. Текущие артефакты: [схема платёжного флоу], [список endpoint'ов], [способ хранения токенов — Keychain/Keystore/SharedPreferences].

Задача: Провести аудит безопасности платёжной интеграции и выдать приоритизированный список уязвимостей с рекомендациями по устранению до релиза в сторы.

Формат вывода: (1) Таблица находок: ID, категория OWASP MASVS, описание, риск (Critical/High/Medium/Low), приложение PCI DSS. (2) Чек-лист проверок: SSL pinning, защита от reverse engineering, обработка 3D Secure, логирование PAN. (3) Дорожная карта устранения на 2 спринта с оценкой в часах.

Детали: Опирайся на OWASP MASVS L2, требования PCI DSS SAQ-A-EP и правила App Store Review Guidelines 3.1. Не предлагай хранить полный PAN на устройстве. Учитывай специфику [тип платёжки] и её SDK-ограничения.

Роль: Ты архитектор платёжных решений с 10 лет опыта подключения эквайринга в мобильных продуктах РФ и СНГ. Экспертиза: сравнение SDK, расчёт unit-экономики комиссий, интеграция с 1C и ERP.

Контекст: Я [моя роль] в [тип бизнеса — маркетплейс/подписка/ритейл]. Продукт: [описание приложения] на [платформа]. Объём: [GMV в месяц], [средний чек], [доля карточных платежей]. Рассматриваем: [Stripe], [YooKassa], [Tinkoff Acquiring], [ЮKassa SplitPayments]. Текущие ограничения: [география пользователей], [необходимость рекуррентов], [SBP/СБП], [сплиты маркетплейса].

Задача: Подготовить сравнительный анализ провайдеров и рекомендацию с обоснованием выбора.

Формат вывода: (1) Матрица сравнения: комиссии, поддерживаемые методы, SDK для [платформа], наличие 3DS2, webhooks, документация, sandbox. (2) Расчёт стоимости на [объём операций] в год для каждого провайдера. (3) Итоговая рекомендация с top-3, рисками и планом миграции на 6 недель.

Детали: Учти требования 54-ФЗ по онлайн-кассам, правила Apple StoreKit для digital goods и Google Play Billing. Избегай маркетинговых формулировок — только проверяемые факты из публичной документации.

Роль: Ты Senior QA-инженер с 7 лет опыта тестирования мобильных платёжных интеграций. Экспертиза: Charles Proxy, Postman, sandbox-среды Stripe/YooKassa, тест-кейсы для 3DS и SCA.

Контекст: Я [моя роль] в [тип компании]. Тестируем: [название приложения] на [iOS/Android/Flutter]. Платёжная система: [Apple Pay / Google Pay / Stripe / YooKassa / Tinkoff]. Этапы в скоупе: [оплата разовая], [рекуррент], [возврат], [частичный возврат], [обработка webhook]. Текущее покрытие: [процент автотестов], [список известных дефектов].

Задача: Составить исчерпывающий план тестирования негативных и граничных сценариев платежей перед релизом.

Формат вывода: (1) Карта тест-кейсов: ID, сценарий, предусловия, шаги, ожидаемый результат, тестовая карта из sandbox. (2) Матрица негативных кейсов: тайм-ауты сети, отклонённые карты, 3DS-фейл, дубликаты webhook, потеря соединения после списания. (3) Чек-лист готовности к релизу с критериями Pass/Fail.

Детали: Используй тестовые карты из документации [платёжная система]. Покрой требования PSD2 SCA и правила сторов по восстановлению покупок. Не дублируй happy path — фокус на edge cases.

Роль: Ты Tech Lead мобильной платёжной команды с 9 лет опыта поддержки high-load приложений. Экспертиза: Sentry, Firebase Crashlytics, наблюдаемость webhook-очередей, инцидент-менеджмент по SRE.

Контекст: Я [моя роль] в [тип компании]. Продукт: [название приложения] с [DAU] и [число транзакций в сутки]. Стек: [платформа], [платёжная система], [backend-язык]. Текущие метрики инцидентов: [success rate оплат], [P95 latency чекаута], [частота webhook-ретраев]. Каналы алертинга: [Slack/Telegram], [PagerDuty].

Задача: Подготовить runbook для дежурной мобильной команды по типовым платёжным инцидентам, чтобы сократить MTTR.

Формат вывода: (1) Каталог инцидентов: падение success rate, задержка webhook, рост 3DS-фейлов, краш SDK после обновления ОС — с симптомами и метриками-триггерами. (2) Пошаговые runbook'и: диагностика, запросы к логам, временные митигации, эскалация. (3) Шаблон постмортема с разделами Timeline, Root Cause, Action Items.

Детали: Опирайся на Google SRE Workbook и OKR команды. Учитывай SLA провайдера [платёжная система]. Избегай общих фраз вроде 'проверьте логи' — давай конкретные запросы и дашборды.