У SaaS есть два обычных способа принимать USDC: разместить постоянную платежную ссылку для фиксированного тарифа или создавать одноразовую checkout session на сервере приложения. Ссылка запускается быстрее. Серверная сессия позволяет надежно передать ID клиента, номер заказа и параметры возврата после оплаты.
Сам перевод USDC не закрывает задачу целиком. Нужны идентификация покупки, подтверждение транзакции, защита от повторной выдачи доступа и понятная история платежа.
Платежная ссылка или серверная checkout session
Постоянная ссылка подходит для лендинга, письма, Telegram-бота или страницы тарифа. В нее можно добавить client_reference_id:
https://app.stendly.com/p/pl_example?client_reference_id=user_8472Такой параметр помогает связать платеж с пользователем, но передается через браузер и может быть изменен вручную. Он не подтверждает, что плательщик действительно владеет аккаунтом user_8472.
Если приложение уже знает авторизованного пользователя, безопаснее создавать checkout session на backend. Сервер передает платежному API ID клиента или заказа, получает временную ссылку и возвращает ее браузеру. Покупатель не может подменить тариф, сумму или доверенный идентификатор через URL.
Минимальная рабочая схема
Приложение создает или выбирает товар и цену. Покупатель открывает hosted checkout и отправляет поддерживаемый стейблкоин. После подтверждения платежный сервис присылает подписанный webhook. SaaS проверяет подпись, убеждается, что событие еще не обработано, и активирует тариф.
Выдавать доступ по открытию success page нельзя. Redirect сообщает браузеру, куда перейти после checkout, но сам по себе не подтверждает платеж.
Для надежной обработки достаточно сохранять несколько полей:
provider_event_id
internal_user_id
price_id
payment_status
fulfilled_at
transaction_referenceWebhook должен быть идемпотентным. Если одно событие придет повторно, обработчик вернет успешный ответ, но не выдаст тариф второй раз.
Что берет на себя Stendly
В Stendly есть постоянные платежные ссылки, серверные checkout sessions, товары, цены, счета, подписки и подписанные webhooks. Начать можно с hosted link, а затем перейти к API, когда появятся динамические заказы или понадобится надежная привязка пользователя.
Stendly принимает поддерживаемые стейблкоины, включая USDC и USDT в сетях Solana и Ethereum. Кошелек и базовая платежная инфраструктура работают на USDC Solana. Во время публичной беты Stendly заявляет 0% комиссии для продавца; сетевые и сторонние расходы, если они возникают, показываются покупателю до подтверждения.
Почему для платежей часто выбирают USDC Solana
USDC выпускается в нескольких сетях. В Solana это SPL-токен, поэтому перевод использует комиссии Solana, а не Ethereum gas. В комиссию транзакции входит базовая плата за подпись и при необходимости priority fee. Если у получателя еще нет associated token account, его создание тоже может добавить расходы.
Низкая комиссия полезна для небольших SaaS-платежей, но доступность токена важнее абстрактной экономии. Если большая часть покупателей уже хранит USDT в TRON, обязательный обмен или bridge может создать больше трения, чем уберет checkout. Это стоит проверять на реальной аудитории.
Частые вопросы
Можно ли отменить подтвержденный перевод USDC?
У подтвержденной блокчейн-транзакции нет процедуры chargeback, похожей на карточную. Это снижает один вид риска для продавца, но ошибочный перевод нельзя автоматически отозвать. Возвраты требуют отдельного процесса.
Нужен ли SOL для отправки USDC в Solana?
Обычному Solana-кошельку нужен SOL для сетевой комиссии. Некоторые платежные сервисы могут спонсировать fee или учитывать его внутри checkout. Точное поведение зависит от кошелька и провайдера.
Можно ли безопасно определить пользователя через платежную ссылку?
Публичный client_reference_id полезен для сверки, но не является авторизацией. Если привязка должна быть доверенной, checkout session следует создавать на backend.