CONSTRUA COM SHAREAI
Dê aos clientes uma escolha clara sobre o uso de IA, sua taxa opcional e cada compra. Construa uma jornada de pagamento que eles possam entender e controlar.
A experiência que você projetará
Pagar com ShareAIAcesso claro. Termos aceitos. Compras confirmadas.
SUA IMPLEMENTAÇÃO
Mantenha a autorização, os termos aceitos e os pagamentos confirmados explícitos tanto no seu produto quanto na sua implementação.
O cliente entende se está conectando, usando IA ou aprovando uma compra.
O token e a operação usam a conta e o escopo pretendidos.
Publique ofertas compreensíveis e acompanhe a versão que cada cliente aceitou.
Novos termos não movem silenciosamente um cliente existente.
Crie uma compra pretendida, verifique seu status de pagamento e a realize uma vez paga.
Repetições, cancelamento, checkout recusado e limites são tratados.
LEVE PARA SEU EDITOR
Copie o guia completo com o objetivo de implementação, entradas necessárias e verificações de aceitação. Mantenha exemplos de código, tabelas e links de documentação juntos.
Pronto para seu projeto, no formato que você precisa.
Atualizado
Você distinguirá conectar uma conta, pagar pelo uso de IA e confirmar uma compra de produto.
Onde você trabalhará Seu produto → Experiência de pagamento
Pay with ShareAI permite que um cliente use sua conta selecionada de ShareAI em seu aplicativo. Existem dois fluxos de cobrança distintos: solicitações de IA financiadas pelo cliente sob uma autorização aceita e uma compra de produto que o cliente confirma no checkout. O markup opcional Builder é um acordo adicional sobre o uso de IA.
| Ação do cliente | O que acontece | Acesso necessário |
|---|---|---|
| Conectar uma carteira | Cria uma autorização para a conta selecionada e os termos aceitos. Nenhum produto é comprado ao clicar em Conectar. | openid além das capacidades que seu aplicativo utiliza. |
| Enviar uma solicitação de IA | Utiliza os créditos de IA elegíveis da conta autorizada e os termos de uso aceitos. | Acesso de inferência aplicável; monetization_gateway para termos de markup aceitos de Builder. |
| Confirmar uma compra de produto | Debita a compra específica somente após a confirmação autorizada. | payments e uma solicitação de pagamento bem-sucedida. |
O exemplo de agendamento de JamZY demonstra a rota de uso de IA. Ele não possui checkout de comerciante, não solicita escopo de pagamentos e não afirma que conectar compra uma assinatura. Use os capítulos restantes ao adicionar essa experiência separada.
Seu botão e cópia do produto indicam se o cliente está conectando, utilizando IA ou confirmando uma compra.
Você obterá permissão da conta pagadora pretendida antes que uma operação a utilize.
Onde você trabalhará Console → Casos de Uso → Autorização do cliente
payments para checkout de produtos, inference para IA a custo de rede e monetization_gateway para um markup de IA aprovado. Solicite apenas as capacidades que o aplicativo realmente utiliza.Um ID de cliente identifica a plataforma. Um token de acesso representa a autorização do cliente aceita. Uma versão de contrato registra os termos de cobrança. Nenhum desses elementos, isoladamente, prova que um pagamento de produto específico foi confirmado.
O token pertence ao cliente pretendido e inclui as permissões para a operação que você está prestes a realizar.
Você publicará termos de uso claros que o cliente pode revisar e aceitar.
Onde você trabalhará Aplicação → Assinaturas
Em Assinaturas, crie ofertas claramente nomeadas e explique a taxa adicional de IA. O ID da assinatura é gerado, somente leitura e vinculado ao seu aplicativo. Essas ofertas são compartilhadas entre os clientes da plataforma do aplicativo, então você não mantém uma oferta comercial diferente para Web e Android.
surcharge para esta oferta.Use Estimar para comparar o custo de rede, sobretaxa e ganhos do builder para o modelo escolhido. Publique um rascunho revisado como a próxima versão do contrato. Os clientes aceitam essa versão durante a autorização; uma oferta publicada não é o mesmo que um acordo aceito pelo cliente.
Se você precisar apenas de payments de produto, use o fluxo de contrato de acesso ao pagamento gratuito disponível em vez de criar um markup Builder. Preços fixos de assinatura e intervalos não são configurados pelo editor de ofertas de uso atual; não interprete uma oferta de IA como cobrança recorrente automática.
Sua oferta descreve com precisão o que é adicionado ao custo de IA. O consentimento voltado para o cliente mostra os mesmos termos publicados.
Você introduzirá um novo contrato enquanto acompanha os termos que cada conta aceitou.
Onde você trabalhará Assinaturas → Contratos
Prepare alterações no próximo rascunho do contrato. Autorizações existentes mantêm sua assinatura e versão aceitas até que o cliente aceite uma substituição. Compare contagens e distribuições de contas na visão geral da assinatura em vez de presumir que todas as contas usam a versão mais recente.
Informe os clientes sobre as alterações e envie-os pelo fluxo de consentimento para aceitar uma nova versão quando necessário. Um token atualizado não pode fabricar aceitação. Manter contratos aceitos é a transição padrão. Optar por exigir consentimento renovado antes de ações adicionais interrompe deliberadamente o acesso existente até que o cliente aprove os novos termos; revise esse impacto antes da publicação. Qualquer redução permitida deve seguir as regras do contrato aceito; um aumento de taxa requer a aprovação do cliente.
Mantenha a visão no nível da aplicação e o limite de identidade separados. Identificadores de clientes específicos da plataforma permanecem limitados ao contexto do cliente, mesmo quando a visão comercial agrega toda a aplicação.
Você pode identificar qual contrato cada conta aceitou e explicar como ela pode migrar para o próximo.
Você criará uma compra pretendida, obterá confirmação e verificará o pagamento antes da entrega.
Onde você trabalhará Seu backend → ShareAI checkout → Verificação de pagamento
Este capítulo estende o exemplo de agendamento com uma compra de produto separada. Execute-o somente após habilitar pagamentos e obter um token de cliente com esse escopo. Mantenha o estado do pedido e do pagamento no seu 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"}'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"| Status de pagamento | O que seu produto deve fazer |
|---|---|
| pendente | Mostre que a confirmação do cliente ainda é necessária. Não conclua ainda. |
| pago | Verifique contra o pedido do servidor, depois conclua uma vez. |
| recusado | Respeite a decisão; deixe o cliente escolher se deseja tentar outra compra. |
| expirado | Crie uma nova solicitação com uma nova chave de idempotência quando o cliente quiser tentar novamente. |
Use apenas uma URL de checkout retornada pela API confiável e valide-a contra a política de destino permitida pela sua integração. Uma mensagem de sucesso de retorno ao aplicativo não é evidência de pagamento. O pagador não pode comprar de sua própria conta de Builder.
Se você oferecer suporte a um contrato de assinatura de preço fixo existente, a API de pagamento pode usar seus termos aceitos para um período explicitamente confirmado. Não envie um preço recorrente inventado nem cobre um novo período silenciosamente. JamZY’s amostra de agendamento para download não implementa essa extensão.
Nenhum pedido é entregue até que seu backend verifique o pagamento, e repetir o fluxo de confirmação não pode entregar ou debitar o mesmo pedido duas vezes.
Você lidará com limites de crédito e desconexões sem cobranças duplicadas ou alterações inesperadas na conta.
Onde você trabalhará Seu aplicativo → Recuperação de cobrança
O uso de IA e as compras de produtos têm regras de crédito elegível diferentes. Uma conta pode ter créditos elegíveis para IA que não podem pagar por um produto. Lide com fundos insuficientes e limites de gastos por aplicativo usando o erro da API e o destino de cobrança do cliente.
Mostre ao cliente a conta pagadora escolhida, a ação que falhou e uma rota para gerenciar créditos ou limites. O cliente controla seu próprio limite; o proprietário do aplicativo não pode aumentá-lo. Não altere silenciosamente de uma conta organizacional para uma conta pessoal para que uma cobrança seja bem-sucedida.
A desconexão deve revogar a autorização relevante e limpar a sessão local. Isso interrompe solicitações autorizadas futuras; não desfaz uma compra já confirmada nem cancela automaticamente um compromisso pago separado. Falha de atualização, revogação de concessão e expiração de pagamento exigem mensagens de recuperação distintas.
Erros de crédito insuficiente e de limite deixam o cliente informado e no controle, sem pedidos duplicados acidentais ou alteração de pagador.
Você testará o caminho bem-sucedido e seus casos de falha antes de incluir a plataforma na publicação.
Onde você trabalhará Configurações de OAuth → Verificação
Use a lista de testadores de todo o aplicativo e uma conta pagadora elegível diferente do Builder. Há no máximo cinco vagas para testadores, incluindo convites pendentes. Conclua a verificação de endpoint real e escopo para cada plataforma incluída na publicação.
inference ou monetization_gateway e a chamada de API de pagamento bem-sucedida necessária para payments. Uma solicitação de pagamento pode estar pendente sem débito; um teste completo de checkout verifica adicionalmente a confirmação explícita e o pagamento.Sua integração distingue acesso aceito, termos aceitos, pagamento solicitado e pagamento confirmado, e lida com o caminho de falha para cada um.
Selecione a conta pessoal ou organizacional que será proprietária da inscrição no programa antes de aplicar. Organizações podem enviar uma aplicação antes da verificação, mas a aprovação da equipe sozinha não ativa o acesso. Complete a verificação de email da organização e da empresa a partir da checklist de onboarding no Console. Uma organização aprovada permanece Pending verification até que ambas as verificações sejam concluídas. Builder, Provider e programas Creator seguem esta regra.
Ver Monetization Gateway preços · Explorar ShareAI for Startups · Escopos e permissões
Seus Termos & Condições públicos, Política de Privacidade e instruções de exclusão devem corresponder ao aplicativo e permanecer acessíveis sem login. A aceitação do programa ShareAI, a aprovação de Monetization Gateway, a permissão OAuth do cliente e o contrato de cobrança aceito são decisões separadas. A atualização não pode adicionar permissões ou aceitar novos termos comerciais.
O escopo legado surcharge continua aceito para integrações existentes. Novos exemplos utilizam monetization_gateway. Mantenha os campos de fio existentes, como surcharge_bps e surcharge_percentage, inalterados.
Ver Monetization Gateway preços · Explorar ShareAI for Startups · Escopos e permissões
Cobranças padrão 5% do markup Builder. Para €2.00 do custo de rede de IA e um markup de 10%, o cliente paga €2.20. ShareAI recebe €0.01 do markup €0.20; o Builder tem €0.19 antes da Ingestão de Eventos.
O primeiro 1,000 pedido de Produção liquidado Monetization Gateway é gratuito a cada mês do calendário (UTC), compartilhado na conta Builder. Pedidos adicionais custam €0.04 por 1,000 antes de descontos elegíveis. Um pedido liquidado cria um evento.
Pay with ShareAI por conta própria, acesso somente inference, chaves de API de conta comum e tráfego de Staging ou teste não geram Ingestão de Eventos Monetization Gateway.
ShareAI for Startups oferece uma cota mensal compartilhada para taxas reais de ShareAI em uma aplicação aprovada. Os níveis atuais de Launch, Growth e Momentum listam €1,000, €5,000 e €10,000 por mês. O mesmo orçamento cobre a taxa percentual de ShareAI sobre o markup de Builder e a ingestão de eventos faturáveis juntos. Não é uma cota de markup bruto, uma cota separada de eventos gratuitos ou inferência de IA gratuita inference. Os primeiros 1,000 eventos gratuitos da conta não consomem essa cota.
As taxas restantes de ingestão de eventos são pagas a partir dos novos ganhos do pedido em Builder, depois dos ganhos de IA disponíveis em Builder e créditos de IA irrestritos. As cobranças de IA do cliente e o produto payments permanecem separados.
ShareAI pode aprovar taxas específicas de aplicação ou suporte de taxas por um período fixo ou até que sejam alteradas. Revise os preços atuais da aplicação e os Programas Especiais no Console para seus termos aprovados, validade e cota consumida. Uma mudança de nível ou substituição de preços não redefine o uso mensal da aplicação.
Launch mantém o Log in com ShareAI como opcional. Growth e Momentum exigem isso; Momentum também exige o selo oficial ShareAI for Startups no rodapé da aplicação. ShareAI verifica o selo semanalmente. Tentativas confirmadas de contornar os requisitos podem levar à despromoção, remoção do Programa Startup ou retirada do Marketplace sob os termos do programa aceitos.
As taxas empresariais são configuradas pela equipe ShareAI para a conta Builder após concordar com uma oferta personalizada. A porcentagem atribuída e a taxa de evento se aplicam a solicitações futuras.
Ver Monetization Gateway preços · Explorar ShareAI for Startups · Escopos e permissões