Платежная ссылка или checkout session
Когда подходит постоянная платежная ссылка, а когда нужна одноразовая сессия, созданная backend.
Платежная ссылка хранит постоянное предложение. Checkout session описывает одну конкретную оплату. Обе могут вести на похожую hosted page, но решают разные задачи.
Постоянная ссылка подходит для фиксированного товара, цены и режима оплаты. Серверная checkout session нужна для динамического заказа или доверенной привязки клиента.
Постоянная платежная ссылка
Ссылку можно поставить на лендинг, отправить в сообщении или превратить в QR-код. Все покупатели открывают один публичный URL. Отдельная платежная сессия создается после начала оплаты.
Через публичные параметры нельзя разрешать изменение цены, проекта, payout address или billing mode.
Для сверки можно передать client_reference_id:
https://app.stendly.com/p/pl_example?client_reference_id=workspace_42Параметр находится в браузере и считается недоверенным. Он годится для метки или низкорисковой атрибуции, но не подтверждает личность.
Одноразовая checkout session
Сессию создает backend продавца для конкретного клиента или заказа. Запрос может содержать доверенный external customer ID, номер заказа, динамическую сумму, return URLs и idempotency key.
Полученная ссылка обычно имеет срок действия и предназначена для одной покупки. Такой вариант безопаснее для внутренних кредитов, приватных workspace и заказов, где подмена reference может передать ценность другому человеку.
Сравнение
| Задача | Payment Link | Checkout Session |
|---|---|---|
| Один фиксированный тариф для многих покупателей | Подходит | Работает, но требует backend |
| Динамическая цена | Не подходит | Подходит |
| Запуск без серверной интеграции | Подходит | Невозможен |
| Доверенная привязка пользователя | Не через открытый query | Подходит |
| Публикация в письме или соцсети | Подходит | Можно, но ссылка создается под заказ |
| Идемпотентное создание заказа | Ограничено началом checkout | Контролируется backend |
Выдача доступа остается отдельной задачей
Ни один тип ссылки не должен активировать продукт только потому, что браузер открыл success page. Продавец ждет подписанное событие, проверяет его и обрабатывает идемпотентно.
Для простой продажи может хватить hosted success. Для SaaS-доступа, кредитов или подписки обычно нужен webhook или другой server-side flow.
Как это устроено в Stendly
Payment Link в Stendly хранит фиксированный товар и цену и используется многократно. При начале оплаты создаются отдельные checkout session, invoice и payment intent. В публичной ссылке можно передать недоверенный client_reference_id.
Billing API и SDK Stendly позволяют создавать checkout sessions напрямую. В этом случае customer и order references задает backend продавца.
Частые вопросы
Заменяет ли платежная ссылка SDK?
Для фиксированного hosted checkout — да. Для изменения базы продавца после оплаты все равно нужна серверная логика.
Может ли покупатель изменить сумму?
Нормально реализованная ссылка игнорирует попытки изменить защищенные поля. Сумма и режим загружаются из сохраненной конфигурации.
Подходит ли ссылка для подписки?
Через нее можно начать фиксированный subscription plan. Автоматичность следующих платежей зависит от модели авторизации. Во многих кошельках покупатель должен отдельно подтвердить следующий счет.