Отличия Sandbox ↔ Production
Песочница повторяет контракт боевого API — адреса методов, структуру запросов, подпись и формат ответов, — но не биллинг. Ниже собрано всё, что ведёт себя иначе, чтобы это не выяснилось уже на боевом контуре.
| Что | Как ведёт себя песочница |
|---|---|
| Деньги | Списаний нет ни при каком сценарии: счёт абонента и баланс карты не меняются |
| Ответы методов | Инвойс хранится в песочнице: GetInvoice возвращает реальные MerchantOrderID, MSISDN и сумму из CreateInvoice. Шаблонными остаются песочные константы — OperatorID и NetworkID приходят не от реального оператора |
| Протоколы | Оба протокола — XML Merchant API v2.9 и REST JSON v3 — работают и в песочнице, и в бою. Различаются только адреса контуров |
| Подтверждение PIN | SMS не отправляется. POST /invoices/{invoice_id}/authorize и XML AuthorizeInvoice ждут фиксированный 1234, три попытки, после третьей — отказ навсегда. Подтверждение контракта — по тому же правилу. Страница оплаты картой принимает любые 4 цифры вместо 3-D Secure |
| 3-D Secure | Переключается настройкой проекта card_3ds_enabled (по умолчанию включена), чтобы можно было прогнать оба режима. В бою такой настройки нет — челлендж включается индивидуально по эквайеру, типу интеграции и фрод-правилам. Единственный сценарий, где меняется состав ответа, — списание по карточному контракту; подробности и кейсы — «Сценарий: 3-D Secure» |
| Песочные ручки | test_info (JSON) и <TestInfo> (XML) задают исход тарификации и задержку коллбека. В боевом контракте этих полей нет — убрать перед переходом. Подробности — «Песочные ручки» |
| Эмуляция ошибок | Отказ вызывается специальными значениями: ERR_NNN внутри merchant_order_id и зарезервированные последние 4 цифры карты 0001–0005. В бою это обычные значения, и такой заказ создастся как настоящий |
| Время тарификации | Имитируется: XML getInvoice первые 6 секунд после первого запроса статуса отдаёт Active / NOT_PAID, затем Processed / PAID. Реальные сроки другие |
| Схема подтверждения | DCB-инвойс всегда возвращает SMS_PIN: выбор схемы оператором мок не эмулирует, хотя спека допускает семь значений AuthorizationType |
| СБП и SberPay | Не различаются — ?useSbp=true и ?payType=Sber ведут на одну и ту же страницу с QR, отличается только экран, выбранный по deviceType |
| Виджет оплаты | Работает со всеми способами и редирект-маршрутом /pay: embed. публикуется, токен приходит в ответе CreateInvoice. Настоящих банков нет, поэтому оплату не подтвердить из приложения банка — довести сценарий до success даёт кнопка симуляции внутри виджета. В бою её нет |
| Дедупликация | Инвойсы дедуплицируются по клиенту, как в бою: пока прежний не закрыт, новый заказ этого же абонента получит 409. Мобильные контракты тоже: повторный merchant_contract_id получит 409 — CONTRACT_DRAFT_EXISTS, пока контракт ждёт PIN, и CONTRACT_ALREADY_EXISTS после подтверждения |
Ответ createInvoice | Код ответа 201 — как в спеке и в бою. Отличие одно: рядом с data. отдаётся устаревший алиас data. |
| Хранение | Журналы запросов и состояние инвойсов чистятся по расписанию: созданный давно инвойс со временем перестаёт находиться |
Коллбеки — настоящие. Уведомления уходят на ваш адрес по-настоящему, с реальной подписью и реальным ретраем. Это та часть интеграции, которую здесь можно отлаживать ровно так же, как в бою — см. «Коллбеки».
Перед переходом в прод: убрать из запросов test_info / <TestInfo>, заменить тестовые merchant_order_id с ERR_NNN и номера карт с зарезервированными последними цифрами, не полагаться на PIN 1234, получить боевые Login и Secret — доступы песочницы в бою не работают.