CONSTRUYE CON SHAREAI
Dé a los clientes una elección clara sobre el uso de IA, su tarifa opcional y cada compra. Construya un recorrido de pago que puedan entender y controlar.
La experiencia que diseñará
Pagar con ShareAIAcceso claro. Términos aceptados. Compras confirmadas.
TU IMPLEMENTACIÓN
Mantenga explícitos la autorización, los términos aceptados y los pagos confirmados tanto en su producto como en su implementación.
El cliente entiende si está conectando, usando IA o aprobando una compra.
El token y la operación utilizan la cuenta y el alcance previstos.
Publique ofertas comprensibles y rastree la versión que cada cliente ha aceptado.
Los nuevos términos no cambian silenciosamente a un cliente existente.
Cree una compra prevista, verifique su estado de pago y cúmplala una vez.
Se manejan reintentos, cancelaciones, pagos rechazados y límites.
LLEVA ESTO A TU EDITOR
Copia la guía completa con el objetivo de implementación, los insumos requeridos y las verificaciones de aceptación. Mantén juntos los ejemplos de código, tablas y enlaces de documentación.
Listo para tu proyecto, en el formato que necesitas.
Actualizado
Distinguirá entre conectar una cuenta, pagar por el uso de IA y confirmar una compra de producto.
Dónde trabajarás Su producto → Experiencia de pago
Pay with ShareAI permite que un cliente use su cuenta seleccionada ShareAI en su aplicación. Hay dos flujos de facturación distintos: solicitudes de IA financiadas por el cliente bajo una autorización aceptada, y una compra de producto que el cliente confirma en el proceso de pago. El marcado opcional Builder es un acuerdo adicional sobre el uso de IA.
| Acción del cliente | Qué sucede | Acceso requerido |
|---|---|---|
| Conectar una billetera | Crea una autorización para la cuenta seleccionada y los términos aceptados. No se compra ningún producto al hacer clic en Conectar. | openid más las capacidades que utiliza tu aplicación. |
| Enviar una solicitud de IA | Utiliza los créditos de IA elegibles de la cuenta autorizada y los términos de uso aceptados. | Acceso de inferencia aplicable; monetization_gateway para los términos de marcado aceptados Builder. |
| Confirmar una compra de producto | Debita la compra en particular solo después de la confirmación autorizada. | payments y una solicitud de pago exitosa. |
La muestra de cita de JamZY demuestra la ruta de uso de IA. No tiene pago en el comercio, no solicita alcance de pagos y no afirma que conectar compre una suscripción. Usa los capítulos restantes cuando agregues esa experiencia por separado.
Tu botón y el texto del producto indican si el cliente está conectando, utilizando IA o confirmando una compra.
Obtendrás permiso de la cuenta de pago prevista antes de que una operación la utilice.
Dónde trabajarás Consola → Casos de uso → Autorización del cliente
payments para el proceso de pago de productos, inference para IA a costo de red, y monetization_gateway para un marcado de IA aprobado. Solicite solo las capacidades que la aplicación realmente utiliza.Un ID de cliente identifica la plataforma. Un token de acceso representa la autorización aceptada del cliente. Una versión de contrato registra los términos de facturación. Ninguno de estos por sí solo prueba que se confirmó el pago de un producto en particular.
El token pertenece al cliente previsto e incluye los permisos para la operación que estás a punto de realizar.
Publicarás términos de uso claros que el cliente pueda revisar y aceptar.
Dónde trabajarás Aplicación → Suscripciones
En Suscripciones, crea ofertas con nombres claros y explica la tarifa adicional de IA. El ID de suscripción se genera, es de solo lectura y está limitado a tu aplicación. Estas ofertas se comparten entre los clientes de la plataforma de la aplicación, por lo que no mantienes una oferta comercial diferente para Web y Android.
surcharge para esta oferta.Usa Estimar para comparar el costo de red, el recargo y las ganancias del builder para el modelo elegido. Publica un borrador revisado como la próxima versión del contrato. Los clientes aceptan esa versión durante la autorización; una oferta publicada no es lo mismo que un acuerdo aceptado por el cliente.
Si solo necesita el producto payments, use el flujo de contrato de acceso de pago gratuito disponible en lugar de inventar un marcado Builder. Los precios y los intervalos de suscripción fijos no se configuran mediante el editor de ofertas de uso actual; no interprete una oferta de IA como facturación recurrente automática.
Su oferta describe con precisión lo que se agrega al costo de IA. El consentimiento orientado al cliente muestra los mismos términos publicados.
Introducirá un nuevo contrato mientras realiza un seguimiento de los términos que cada cuenta ha aceptado.
Dónde trabajarás Suscripciones → Contratos
Prepare cambios en el próximo borrador del contrato. Las autorizaciones existentes conservan su suscripción y versión aceptadas hasta que el cliente acepte un reemplazo. Compare los recuentos y distribuciones de cuentas en la vista general de suscripciones en lugar de asumir que todas las cuentas usan la última versión.
Informe a los clientes sobre los cambios y envíelos a través del flujo de consentimiento para aceptar una nueva versión cuando sea necesario. Un token actualizado no puede fabricar aceptación. Mantener los contratos aceptados es la transición predeterminada. Elegir requerir un nuevo consentimiento antes de realizar más acciones interrumpe deliberadamente el acceso existente hasta que el cliente apruebe los nuevos términos; revise ese impacto antes de la publicación. Cualquier disminución permitida debe seguir las reglas del contrato aceptado; un aumento de tarifa requiere la aprobación del cliente.
Mantenga separada la vista a nivel de aplicación y el límite de identidad. Los identificadores de clientes específicos de la plataforma permanecen limitados a su contexto de cliente, incluso cuando la vista general comercial agrega toda la aplicación.
Puede identificar qué contrato aceptó cada cuenta y explicar cómo puede pasar al siguiente.
Creará una compra prevista, obtendrá confirmación y verificará el pago antes de la entrega.
Dónde trabajarás Su backend → ShareAI checkout → Verificación de pago
Este capítulo amplía el ejemplo de cita con una compra de producto separada. Ejecútelo solo después de habilitar los pagos y obtener un token de cliente con ese alcance. Mantenga el estado del pedido y del pago en su 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"| Estado del pago | Lo que su producto debería hacer |
|---|---|
| pendiente | Muestre que aún se requiere la confirmación del cliente. No cumpla todavía. |
| pagado | Verifique contra el pedido de su servidor, luego cumpla una vez. |
| rechazado | Respete la decisión; permita que el cliente elija si desea intentar otra compra. |
| expirado | Cree una nueva solicitud con una nueva clave de idempotencia cuando el cliente desee reintentar. |
Use solo una URL de pago devuelta por la API confiable y valídala contra la política de destino permitida de tu integración. Un mensaje de éxito de retorno a la aplicación no es evidencia de pago. El pagador no puede comprar desde su propia cuenta de Builder.
Si admites un contrato de suscripción de precio fijo existente, la API de pago puede usar sus términos aceptados para un período explícitamente confirmado. No envíes un precio recurrente inventado ni cobres un nuevo período de manera silenciosa. JamZY’s muestra descargable de cita no implementa esa extensión.
Ningún pedido se entrega hasta que tu backend verifique el pago, y repetir el flujo de confirmación no puede entregar ni debitar el mismo pedido dos veces.
Manejarás límites de crédito y desconexiones sin cargos duplicados ni cambios inesperados en la cuenta.
Dónde trabajarás Tu aplicación → Recuperación de facturación
El uso de IA y las compras de productos tienen reglas de crédito elegible diferentes. Una cuenta puede tener créditos elegibles para IA que no pueden pagar un producto. Maneja fondos insuficientes y límites de gasto por aplicación utilizando el error de la API y el destino de facturación del cliente.
Muestra al cliente la cuenta de pago elegida, la acción que falló y una ruta para gestionar créditos o límites. El cliente controla su propio límite; el propietario de la aplicación no puede aumentarlo. No cambies silenciosamente de una cuenta de organización a una personal para que un cargo tenga éxito.
La desconexión debe revocar la autorización relevante y borrar la sesión local. Detiene solicitudes autorizadas futuras; no deshace una compra ya confirmada ni cancela automáticamente un compromiso pagado por separado. La falla de actualización, la revocación de concesión y el vencimiento del pago requieren mensajes de recuperación distintos.
Los errores de crédito insuficiente y límite dejan al cliente informado y en control, sin pedidos duplicados accidentales ni cambios de pagador.
Probarás el camino exitoso y sus casos de falla antes de incluir la plataforma en la publicación.
Dónde trabajarás Configuración de OAuth → Verificación
Usa la lista de probadores de toda la aplicación y una cuenta de pago elegible diferente del Builder. Hay un máximo de cinco lugares para probadores, incluidas las invitaciones pendientes. Completa la verificación real del endpoint y del alcance para cada plataforma incluida en la publicación.
inference o monetization_gateway y la llamada API de pago exitosa requerida para payments. Una solicitud de pago puede estar pendiente sin débito; una prueba completa de proceso de pago verifica adicionalmente la confirmación explícita y el pago realizado.Tu integración distingue acceso aceptado, términos aceptados, pago solicitado y pago confirmado, y maneja la ruta de fallo para cada uno.
Seleccione la cuenta personal u organizacional que será propietaria de la inscripción al programa antes de aplicar. Las organizaciones pueden enviar una solicitud antes de la verificación, pero la aprobación del personal por sí sola no activa el acceso. Complete la verificación del correo electrónico de la organización y de la empresa desde la lista de verificación de incorporación en la Consola. Una organización aprobada permanece Pendiente de verificación hasta que ambos controles estén completos. Builder, Provider y Creator programas siguen esta regla.
Ver precios de Monetization Gateway · Explora ShareAI for Startups · Alcances y permisos
Sus Términos y Condiciones públicos, Política de Privacidad e instrucciones de eliminación deben coincidir con la aplicación y permanecer accesibles sin iniciar sesión. La aceptación del programa ShareAI, la aprobación de Monetization Gateway, el permiso OAuth del cliente y el contrato de facturación aceptado son decisiones separadas. La actualización no puede agregar permisos ni aceptar nuevos términos comerciales.
El alcance heredado surcharge sigue siendo aceptado para integraciones existentes. Los nuevos ejemplos usan monetization_gateway. Mantenga los campos de transferencia existentes como surcharge_bps y surcharge_percentage sin cambios.
Ver precios de Monetization Gateway · Explora ShareAI for Startups · Alcances y permisos
Cargos estándar 5% del margen Builder. Para €2.00 del costo de red de IA y un margen 10%, el cliente paga €2.20. ShareAI recibe €0.01 del margen €0.20; el Builder tiene €0.19 antes de la Ingesta de Eventos.
Los primeros 1,000 pedidos de Producción liquidados Monetization Gateway son gratuitos cada mes calendario (UTC), compartidos en la cuenta Builder. Los pedidos adicionales cuestan €0.04 por 1,000 antes de aplicar los descuentos elegibles. Un pedido liquidado crea un evento.
Pay with ShareAI por sí solo, acceso solo a inference, claves API de cuentas ordinarias y tráfico de Staging o pruebas no incurren en la tarifa de Ingestión de Eventos Monetization Gateway.
ShareAI for Startups ofrece una asignación mensual compartida para las tarifas reales de ShareAI en una aplicación aprobada. Los niveles actuales de Launch, Growth y Momentum enumeran €1,000, €5,000 y €10,000 por mes. El mismo presupuesto cubre la tarifa porcentual de ShareAI sobre el margen de Builder y la Ingestión de Eventos facturable juntos. No es una asignación de margen bruto, una cuota de eventos gratuitos separada ni una inference de IA gratuita. Los primeros 1,000 eventos gratuitos de la cuenta no lo consumen.
Las tarifas restantes de Ingestión de Eventos se pagan con las nuevas ganancias de la solicitud en Builder, luego con las ganancias de IA disponibles en Builder y los créditos de IA no restringidos. Los cargos de IA del cliente y el producto payments permanecen separados.
ShareAI puede aprobar tarifas específicas de la aplicación o soporte de tarifas por un período fijo o hasta que se modifique. Revise los precios actuales de la aplicación y los Programas Especiales en la Consola para conocer sus términos aprobados, validez y asignación consumida. Un cambio de nivel o una anulación de precios no restablece el uso mensual de la aplicación.
Launch mantiene el inicio de sesión con ShareAI como opcional. Growth y Momentum lo requieren; Momentum también requiere la insignia oficial ShareAI for Startups en el pie de página de la aplicación. ShareAI verifica la insignia semanalmente. Los intentos confirmados de eludir los requisitos pueden llevar a la degradación, la eliminación del Programa Startup o la retirada del Marketplace bajo los términos aceptados del programa.
Las tarifas empresariales son configuradas por el equipo ShareAI para la cuenta Builder después de acordar una oferta personalizada. El porcentaje asignado y la tarifa por evento se aplican a solicitudes futuras.
Ver precios de Monetization Gateway · Explora ShareAI for Startups · Alcances y permisos