Миграция PayPal JavaScript SDK v6 в 2026: приёмка Safari

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

Сначала составьте карту входов:

• карточка товара;
• корзина;
• основная страница оформления;
• отдельная кнопка на странице подписки;
• быстрый заказ;
• промо-страница или локализованный американский лендинг.

Для каждого входа запишите:

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

Не доверяйте только исходному коду шаблона. Откройте Safari Web Inspector и проверьте фактический сетевой запрос. В проекте может остаться старая страница, кешированный скрипт или второй компонент, который продолжает работать по прежней схеме. Инструкция PayPal по подключению JavaScript SDK помогает сопоставить параметры загрузки с тем, что действительно происходит в браузере.

Отдельно сопоставьте три состояния:

1. кнопка видна;
2. покупатель может пройти авторизацию и одобрение;
3. сервер подтвердил захват и создал заказ.

Только третье состояние связано с фактической готовностью к исполнению заказа. Успешная анимация или возврат на страницу магазина не заменяют серверную проверку.

В песочнице начните с минимального сценария. Не подключайте сразу все способы оплаты и рекламные виджеты. Цель первого прохода — понять, загружается ли компонент PayPal Checkout и не ломает ли миграция страницу.

Проверьте четыре входа:

• первый визит на страницу;
• ручное обновление;
• возврат из корзины;
• повторный вход в оформление после неудачной попытки.

При каждом проходе сохраняйте:

• снимок экрана;
• URL страницы;
• время проверки;
• ошибки консоли;
• запрос загрузки SDK;
• ответ инициализации;
• видимые способы оплаты.

Состав отображаемых способов оплаты не следует считать универсальным. Он может зависеть от страны, валюты, устройства, настроек покупателя и доступности конкретного метода. Фиксируйте фактический результат тестового аккаунта, а не обещайте, что тот же набор увидит каждый покупатель.

Что проверять при пустом месте вместо кнопки

Если PayPal v6 в Safari не показывает кнопку, двигайтесь от наблюдаемого факта к причине:

1. убедитесь, что запрос к SDK не получил ошибку;
2. проверьте, не загружен ли скрипт дважды;
3. сравните момент инициализации с моментом появления контейнера;
4. проверьте клиентские параметры и окружение песочницы;
5. изучите Content Security Policy;
6. повторите тест после очистки данных только для тестового домена;
7. сравните результат с другим браузером.

Инструменты разработчика Safari нужно включить заранее. Apple описывает путь к функциям разработчика и Web Inspector в официальной документации Safari Developer Tools. В отчёте указывайте, какой именно запрос отсутствует или завершается ошибкой. Формулировка «кнопка не работает» для передачи подрядчику слишком неточна.

Опыт приёмки: повторная загрузка после возврата из корзины часто выявляет проблему, которую не видно при первом визите. Поэтому один успешный вход не закрывает проверку инициализации.

Окно авторизации нужно проверять отдельно от кнопки. В Safari изменяйте только одну переменную за проход:

• состояние входа покупателя;
• данные сайта;
• настройки межсайтового отслеживания;
• блокировку всплывающих окон;
• расширения;
• наличие предыдущей незавершённой сессии.

Сначала используйте чистый профиль с минимальным числом расширений. Затем повторите сценарий в обычном рабочем профиле. Это позволит отделить дефект интеграции от локальной настройки браузера.

Нужны следующие результаты:

• окно открывается;
• покупатель закрывает его сам;
• Safari блокирует окно;
• вход прерывается;
• покупатель возвращается без одобрения;
• после ошибки доступна повторная попытка.

Проверьте настройки всплывающих окон по руководству Apple для Safari, но не превращайте разрешение всех окон в рекомендацию для покупателей. Если платёж проходит только после отключения встроенной защиты или изменения параметров конфиденциальности, это не пройденный сценарий, а сигнал для технического разбора. Описание соответствующих механизмов есть в документации Apple о конфиденциальности Safari.

Стабильный удалённый Mac помогает повторять этот тест в одинаковом браузерном профиле. Но он не меняет политику PayPal и не гарантирует допуск операции. Среда нужна для диагностики, а не для обхода проверки личности, ограничений аккаунта или правил платёжной системы.

После входа выполните два разных сценария: одобрение и добровольная отмена. Не объединяйте их в один тест, иначе команда может принять возврат без оплаты за успешное завершение.

При одобрении зафиксируйте:

• идентификатор заказа PayPal;
• результат клиентского обработчика;
• запрос магазина на сервер;
• ответ сервера;
• изменение статуса корзины;
• итоговую запись в панели магазина.

При отмене проверьте:

• сохраняется ли корзина;
• не очищается ли товар преждевременно;
• появляется ли понятное сообщение;
• можно ли повторить платёж;
• не создаётся ли пустой заказ;
• не отправляется ли товар в обработку.

Точно так же проверьте возврат после закрытия окна и после ошибки загрузки компонента. Пользователь должен понимать, что делать дальше. Скрытая ошибка в консоли не является интерфейсом восстановления.

В материалах PayPal по расширенной настройке SDK следует сверить используемый способ обработки клиентских событий и серверных действий. Код в статье намеренно не приводится целиком: для приёмки важнее подтвердить фактические запросы и состояния, чем скопировать пример без учёта архитектуры магазина.

Главная граница ответственности проходит между браузером и сервером. Браузер может показать, что покупатель одобрил платёж, но это ещё не означает завершённый capture или созданный заказ.

Технический участник приёмки должен сопоставить:

• создание PayPal-заказа;
• одобрение покупателем;
• запрос на захват;
• ответ API;
• внутренний статус заказа;
• запись об оплате;
• уведомление или вебхук, если он используется.

Оператор проверяет то же событие с другой стороны: виден ли заказ в независимой системе магазина и совпадает ли он с активностью в тестовой среде PayPal. Для диагностики ошибок используйте официальный обзор ошибок PayPal API, а не догадки по одному сообщению на экране.

Обязательные отрицательные сценарии:

• покупатель отменил оплату;
• платёжный метод отклонён;
• сервер вернул ошибку;
• клиент повторил действие;
• сеть прервалась после одобрения;
• страница была обновлена до получения результата.

Все отрицательные проверки выполняйте только с официальными тестовыми средствами и данными песочницы. Не используйте реальные карты для имитации отказов. Если PayPal показывает успешную активность, но магазин не создаёт заказ, проверяйте серверную идемпотентность, обработку ответа и границу между capture и созданием заказа.

Финальный прогон должен проходить в изолированном реальном Safari. Сравнение с другим браузером полезно для локализации причины, но не может заменить Safari-приёмку. Таблица поддержки браузеров PayPal должна быть проверена перед публикацией и при каждом изменении требований.

Зафиксируйте тестовые переменные:

• американская посадочная страница;
• целевая валюта;
• язык интерфейса;
• товар с обычной ценой;
• товар с доставкой;
• чистая сессия;
• тестовый покупатель песочницы;
• версия Safari;
• сетевой маршрут;
• время начала и окончания.

Не делайте вывод о реальном рынке по одной песочнице. Среда должна отвечать вопросу: повторяется ли пользовательский путь и подтверждается ли результат на сервере. Она не должна использоваться для обхода географических правил, проверки аккаунта или требований PayPal.

Если собственной машины нет, можно рассмотреть удалённый Mac с американским узлом для повторяемого теста. Перед арендой проверьте, кто получает доступ, как очищаются данные сайта и каким способом команда сохраняет обезличенные доказательства. Для другого сетевого маршрута можно сравнить американский западный узел Mac, но разница маршрутов сама по себе не доказывает дефект PayPal.

Приёмочная матрица перед выпуском

Перед тем как подписывать результат подрядчика, мы отмечаем пункты только после фактической проверки:

• [ ] Для каждой страницы записана реально загружаемая версия SDK.
• [ ] Старая рабочая версия сохранена как точка отката.
• [ ] Проверены первый вход, обновление, возврат из корзины и повторное оформление.
• [ ] Сохранены сетевой запрос SDK и ошибки Safari Web Inspector.
• [ ] Проверены открытие, закрытие и блокировка окна входа.
• [ ] Настройки Safari менялись по одной, а не одновременно.
• [ ] Отдельно выполнены одобрение и отмена платежа.
• [ ] Состояние корзины проверено после отмены и ошибки.
• [ ] Идентификатор PayPal сопоставлен с внутренним заказом.
• [ ] Серверный capture подтверждён ответом API.
• [ ] Проверены отказ, серверная ошибка и повторное действие.
• [ ] Американская страница проверена в изолированном Safari.
• [ ] Скриншоты обезличены.
• [ ] В отчёте указаны дата, версия браузера, среда и итог заказа.
• [ ] Решение о выпуске подписано ответственным за бизнес и техническую часть.

Последний пункт важен для внешней разработки. Если подрядчик показывает только скриншот зелёной страницы, запросите журнал запроса, идентификатор заказа и серверный статус. Без этой связки результат нельзя считать готовым к исполнению заказа.

Напоминание: PayPal указывает в руководстве для продуктивной среды, что настройки для production нужно проверять отдельно. Успешный тест в песочнице не разрешает автоматически переносить непроверенные ключи, URL и серверные условия в боевой магазин.

Локальная машина удобна, если команда постоянно тестирует Safari, имеет контролируемые профили и может безопасно разделять рабочие данные. Но один общий компьютер создаёт очереди, смешивает cookies и затрудняет повтор сценария другим сотрудником.

Обычный другой браузер полезен как контрольная группа. Он быстро показывает, что серверная часть в целом отвечает. Однако успех в нём не доказывает готовность Safari.

Удалённый Mac рационален для короткого цикла приёмки, внешней команды или распределённого отдела. Он даёт отдельную macOS-сессию, повторяемый браузерный профиль и возможность проверить американский сетевой маршрут. При этом остаются ограничения: удалённое подключение не заменяет реальное устройство покупателя, не гарантирует платёж и требует дисциплины в очистке данных. Вопросы длительности аренды и доступа лучше уточнить до запуска через условия заказа удалённого Mac.

Миграция PayPal JavaScript SDK v6 в 2026 году должна приниматься как проверка цепочки, а не как визуальная проверка кнопки. Пока не подтверждены окно входа, отмена, возврат, серверный capture и запись заказа, обновление остаётся незавершённым. Единый срок принудительного отказа от v5 нельзя объявлять без официального сообщения PayPal, поэтому сохраняйте рабочую ветку и фиксируйте актуальность документации перед выпуском.

Если текущий вариант — один общий локальный Mac или проверка только в другом браузере, у него есть три реальных недостатка: смешиваются данные сессий, трудно повторить американский маршрут, а доказательства зависят от одного рабочего места. Временная аренда удалённого Mac у MESHLAUNCH удобнее для короткой приёмки, когда нужен отдельный Safari, контролируемый доступ и повторяемый сценарий без покупки дополнительного оборудования. После завершения матрицы команда сможет спокойно решить, нужен ли постоянный Mac, ограниченный выпуск или ещё один цикл исправлений.