Оплатить с ShareAI, от согласия до оформления заказа

Выберите, за что платит ваш клиент

Вы будете различать подключение аккаунта, оплату за использование ИИ и подтверждение покупки продукта.

Где вы будете работать Ваш продукт → Опыт оплаты

Pay with ShareAI позволяет клиенту использовать выбранный ShareAI аккаунт в вашем приложении. Существуют два отдельных потока выставления счетов: запросы AI, финансируемые клиентом, в рамках принятого разрешения, и покупка продукта, которую клиент подтверждает при оформлении заказа. Дополнительная разметка Builder является дополнительным соглашением об использовании AI.

JamZY · справочное приложение для встреч Увеличить скриншот ↗

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

Получите авторизацию клиента

Вы получите разрешение от предполагаемого платящего аккаунта до того, как операция его использует.

Где вы будете работать Консоль → Сценарии использования → Авторизация клиента

1. Создайте приложение и завершите процесс регистрации, публичную информацию и обратные вызовы платформы. Включите соответствующие сценарии использования в Консоли.
2. Для разметки Builder завершите запрос на доступ и дождитесь одобрения, если это требуется. Для покупок включите Pay with ShareAI и настройте необходимый договор на доступ к оплате в Подписках.
3. Запрашивайте включенные области через Authorization Code + S256 PKCE. Используйте payments для оформления заказа на продукт, inference для AI по сетевой стоимости и monetization_gateway для одобренной разметки AI. Запрашивайте только те возможности, которые приложение действительно использует.
4. Попросите клиента выбрать правильный личный или организационный аккаунт и принять отображаемые условия. Дополнительные области или измененные условия требуют повторной авторизации; обновление не предоставляет их.

Сценарии использования Увеличить скриншот ↗

Идентификатор клиента определяет платформу. Токен доступа представляет принятую авторизацию клиента. Версия контракта фиксирует условия оплаты. Ни один из этих элементов сам по себе не доказывает, что конкретная оплата продукта была подтверждена.

Объясните вашу плату за ИИ в предложении

Вы опубликуете четкие условия использования, которые клиент сможет просмотреть и принять.

Где вы будете работать Приложение → Подписки

В Подписках создайте четко названные предложения и объясните дополнительную плату за ИИ. Идентификатор подписки создается, доступен только для чтения и привязан к вашему приложению. Эти предложения разделяются между клиентами платформы приложения, поэтому вы не поддерживаете отдельное коммерческое предложение для Web и Android.

Подписки · Обзор Увеличить скриншот ↗

Подписки · редактор предложений Увеличить скриншот ↗

Используйте Estimate для сравнения сетевых затрат, дополнительной платы и доходов разработчика для выбранной модели. Опубликуйте проверенный черновик как следующую версию контракта. Клиенты принимают эту версию во время авторизации; опубликованное предложение не является тем же самым, что и принятое клиентом соглашение.

Если вам нужен только продукт payments, используйте доступный бесплатный поток договора на доступ к оплате, а не изобретайте разметку Builder. Фиксированные цены и интервалы подписки не настраиваются текущим редактором предложений по использованию; не интерпретируйте предложение AI как автоматическое повторяющееся выставление счетов.

Позвольте клиентам выбрать новые условия

Вы введете новый контракт, отслеживая условия, которые принял каждый аккаунт.

Где вы будете работать Подписки → Контракты

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

Подписки · Контракты Увеличить скриншот ↗

Сообщите клиентам об изменениях и проведите их через процесс согласия для принятия новой версии, если это требуется. Обновленный токен не может создать согласие. Сохранение принятых контрактов является стандартным переходом. Выбор требования обновленного согласия перед дальнейшими действиями намеренно прерывает существующий доступ до тех пор, пока клиент не одобрит новые условия; оцените это влияние перед публикацией. Любое разрешенное уменьшение должно соответствовать правилам принятого контракта; увеличение платы требует одобрения клиента.

Разделяйте представление на уровне приложения и границы идентичности. Идентификаторы клиентов, специфичные для платформы, остаются в рамках их клиентского контекста, даже если коммерческий обзор агрегирует все приложение.

Подтвердите покупку перед ее выполнением

Вы создадите одну предполагаемую покупку, получите подтверждение и проверите оплату перед доставкой.

Где вы будете работать Ваш backend → ShareAI checkout → Проверка оплаты

Эта глава расширяет пример с назначением встречи отдельной покупкой продукта. Запустите это только после включения платежей и получения токена клиента с этим объемом. Сохраняйте состояние заказа и оплаты на вашем backend.

# Real payment request: use scoped test access and an intentional amount.
curl --fail-with-body 'https://api.shareai.now/api/v1/console/builder/payments' \
  -H "Authorization: Bearer $SHAREAI_ACCESS_TOKEN" \
  -H 'Content-Type: application/json' \
  -H 'Idempotency-Key: YOUR_UNIQUE_ORDER_REFERENCE' \
  --data '{"title":"JamZY appointment preparation pack","amount":"1.00"}'

1. Сохраните возвращенный идентификатор оплаты и URL checkout с заказом. Используйте точную строку с десятичным значением; избегайте вычислений денежных сумм с плавающей запятой.
2. Откройте возвращенный URL checkout. ShareAI представляет покупку и плательщика. Клиент должен подтвердить, используя аккаунт, который авторизовал ваше приложение. Открытие checkout не списывает средства.
3. Прочитайте оплату из API с той же авторизацией клиента. Выполните заказ только после подтвержденного статуса "оплачено".
4. Повторите ту же предполагаемую покупку с тем же ключом идемпотентности. Для другой покупки требуется новый ключ. Никогда не используйте ключ повторно для измененных условий.

curl --fail-with-body --get \
  'https://api.shareai.now/api/v1/console/builder/payments' \
  -H "Authorization: Bearer $SHAREAI_ACCESS_TOKEN" \
  --data-urlencode "id=$SHAREAI_PAYMENT_ID"

Используйте только URL оформления заказа, возвращенный доверенным API, и проверьте его в соответствии с политикой разрешенных направлений вашей интеграции. Сообщение об успешном возврате в приложение не является доказательством оплаты. Плательщик не может совершать покупки со своего собственного аккаунта Builder.

Если вы поддерживаете существующий контракт на подписку с фиксированной ценой, платежный API может использовать его принятые условия для явно подтвержденного периода. Не отправляйте вымышленную повторяющуюся цену и не взимайте плату за новый период без уведомления. JamZY’s загружаемый пример назначения не реализует это расширение.

Помогите клиентам восстановиться после проблемы с оплатой

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

Где вы будете работать Ваше приложение → Восстановление биллинга

Использование AI и покупки продуктов имеют разные правила для кредитов, на которые они распространяются. У аккаунта могут быть кредиты, подходящие для AI, которые не могут быть использованы для оплаты продукта. Обрабатывайте недостаток средств и лимиты расходов на приложение с помощью ошибки API и направления клиента к месту назначения биллинга.

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

Клиенты Увеличить скриншот ↗

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

Проверьте полный процесс оплаты

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

Где вы будете работать Настройки OAuth → Проверка

Используйте общий список тестеров приложения и подходящий аккаунт для оплаты, отличный от Builder. Всего может быть не более пяти мест для тестеров, включая ожидающие приглашения. Завершите проверку реальных конечных точек и областей для каждой платформы, включенной в публикацию.

Веб · Проверка Увеличить скриншот ↗

1. Протестируйте принятие и отмену авторизации; подтвердите границы выбранного клиента/аккаунта.
2. Протестируйте успешный запрос AI с областью inference или monetization_gateway и необходимый успешный вызов API оплаты для payments. Запрос на оплату может быть в ожидании без списания; полный тест оформления заказа дополнительно проверяет явное подтверждение и оплату.
3. Протестируйте дублирующие запросы, отклоненные и истекшие оформления заказа, недостаток подходящих кредитов, лимиты расходов аккаунта, истекшие токены, ротацию обновлений и отозванную авторизацию.
4. Проверьте разделы Клиенты, Подписки и Аналитика для соответствующего клиента, принятых условий и атрибутированной активности. Убедитесь, что конфиденциальные учетные данные и внутренние идентификаторы организаций не отображаются в пользовательском интерфейсе, видимом клиенту.
5. Включайте только платформы, чья конфигурация и записанные проверки пройдены. Исключите незавершенные платформы или удалите их; затем отправьте приложение из Dashboard.

Проверка организации и доступ к программе

Выберите личный или организационный аккаунт, который будет владеть программой регистрации перед применением. Организации могут подать заявку до проверки, но одобрение сотрудниками само по себе не активирует доступ. Завершите проверку электронной почты организации и компании из контрольного списка на этапе онбординга в Console. Одобренная организация остается в статусе Pending verification до завершения обеих проверок. Builder, Provider и программы Creator следуют этому правилу.

Просмотреть Monetization Gateway ценообразование · Изучите ShareAI for Startups · Области и разрешения

Разрешения и принятые условия

Ваши публичные Условия & Положения, Политика конфиденциальности и инструкции по удалению должны соответствовать приложению и оставаться доступными без входа в систему. Принятие программы ShareAI, одобрение Monetization Gateway, разрешение OAuth клиента и принятый договор на оплату являются отдельными решениями. Обновление не может добавлять разрешения или принимать новые коммерческие условия.

Устаревшая область surcharge остается принятой для существующих интеграций. Новые примеры используют monetization_gateway. Сохраните существующие поля проводки, такие как surcharge_bps и surcharge_percentage, без изменений.

Просмотреть Monetization Gateway ценообразование · Изучите ShareAI for Startups · Области и разрешения

Сборы шлюза и поддержка Startup

Стандартные сборы 5% из Builder наценки. Для €2.00 сетевой стоимости ИИ и 10% наценки клиент платит €2.20. ShareAI получает €0.01 из €0.20 наценки; Builder имеет €0.19 до обработки событий.

Первые 1,000 урегулированные Production Monetization Gateway запросы бесплатны каждый календарный месяц (UTC), совместно используются в рамках учетной записи Builder. Дополнительные запросы стоят €0.04 за 1,000 до применения соответствующих скидок. Один урегулированный запрос создает одно событие.

Pay with ShareAI сам по себе, доступ только для вывода (inference-only access), обычные ключи API аккаунта и трафик Staging или тестирования не влекут за собой Monetization Gateway сбор за обработку событий.

ShareAI for Startups предлагает общий ежемесячный лимит для фактических сборов ShareAI на утвержденное приложение. Текущие уровни Launch, Growth и Momentum включают €1,000, €5,000 и €10,000 в месяц. Тот же бюджет покрывает процентную комиссию ShareAI на наценку Builder и оплачиваемую обработку событий вместе. Это не лимит на валовую наценку, отдельная квота на бесплатные события или бесплатный ИИ inference. Первые 1,000 бесплатные события аккаунта не расходуют этот лимит.

Оставшиеся сборы за обработку событий оплачиваются из новых доходов запроса Builder, затем доступных доходов ИИ Builder и неограниченных кредитов ИИ. Расходы на ИИ клиента и продукт payments остаются отдельными.

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

Launch оставляет вход через ShareAI необязательным. Growth и Momentum требуют его; Momentum также требует официального значка ShareAI for Startups в нижнем колонтитуле приложения. ShareAI проверяет значок еженедельно. Подтвержденные попытки обойти требования могут привести к понижению уровня, удалению из программы Startup или исключению из Marketplace в рамках принятых условий программы.

Корпоративные тарифы настраиваются командой ShareAI для аккаунта Builder после согласования персонализированного предложения. Назначенный процент и ставка за событие применяются к будущим запросам.

Просмотреть Monetization Gateway ценообразование · Изучите ShareAI for Startups · Области и разрешения