Solicita conectar tu tienda
Envía tu sitio web después de iniciar sesión con Telegram y sigue cada etapa de revisión en una URL privada. Las verificaciones automáticas apoyan al revisor; un moderador siempre toma la decisión final.
En esta página
Envía una solicitud#
Las descripciones requieren de 40 a 3000 caracteres; los nombres de proyecto permiten hasta 100. El sitio web debe ser accesible sin iniciar sesión. Las URLs que contienen credenciales, hosts privados, puertos no estándar o parámetros de consulta no se aceptan.
La cuenta verificada es dueña de la solicitud. El contacto de Telegram ingresado es para comunicación y no cambia la propiedad. Reenviar la URL de seguimiento no otorga acceso a otra cuenta.
- 1
Inicia sesión o regístrate con Telegram, luego abre /account#applications.
- 2
Ingresa una dirección de sitio web HTTPS pública, nombre del proyecto, categoría y una descripción de tus productos o servicios.
- 3
Añade un contacto de Telegram. Explica qué reciben los clientes y cómo se cumplen los pedidos.
- 4
Confirma tu autoridad para enviar el sitio y envía el formulario.
- 5
Guarda la dirección /account#applications/{id} que se abre inmediatamente después del envío.
Cuatro etapas de revisión#
La línea de conexión y los marcadores de etapa reflejan estados persistidos en el servidor. Reabrir la página continúa el mismo proceso. Cerrar la pestaña no cancela tu solicitud; los trabajos en segundo plano continúan y recuperan etapas interrumpidas.
| Etapa | Qué sucede | Estado mostrado |
|---|---|---|
| Solicitud recibida | Los detalles del envío y la URL privada están guardados | La primera etapa está completa |
| Revisión de contenido | La IA compara la descripción con el contenido del sitio web público | En curso, completa o en espera de un especialista |
| Verificaciones técnicas | Se examinan la disponibilidad y un conjunto acotado de enlaces | Un resultado separado y la marca de tiempo de la etapa |
| Revisión de especialista | Un moderador revisa el envío y los hallazgos | En espera de decisión, aprobada o un motivo de rechazo |
Una etapa amarilla necesita un especialista#
Una marca amarilla significa que una etapa requiere atención, por ejemplo porque la información es insuficiente, un enlace no está disponible o un resultado automatizado no puede aceptarse con confianza. No es un rechazo definitivo. La página de estado explica el siguiente paso.
Un moderador puede limpiar la etapa actual para que continúe la siguiente verificación. Una etapa rechazada muestra una cruz y un motivo visible para el usuario que el moderador puede editar antes de enviar. Limpiar una etapa intermedia nunca elimina la revisión manual final.
Qué cubren las verificaciones automatizadas#
Las verificaciones examinan la página de inicio pública: HTTPS, respuesta HTTP, título, texto y patrones de enlaces sospechosos. También solicitan encabezados de como máximo tres enlaces en el mismo sitio web. El número de redirecciones, el tamaño de la respuesta y el tiempo de solicitud están limitados.
Las verificaciones no acceden a áreas con inicio de sesión, no ejecutan archivos descargados ni reemplazan una auditoría de seguridad o un escáner de malware. Completar una etapa no garantiza que cada página esté libre de contenido malicioso.
El contenido del sitio web son datos no confiables. Las instrucciones en un sitio web no pueden asignar un administrador, cambiar los términos de Kevmi ni aprobar una solicitud. La IA no disponible y la salida del modelo mal formada requieren revisión de un especialista en lugar de pasar la etapa silenciosamente.
Actualizaciones de Telegram#
Recibir una solicitud, completar una etapa, solicitar atención de un especialista y tomar una decisión final generan notificaciones con un enlace de seguimiento privado. Estas usan la categoría Soporte en la configuración de notificaciones de la cuenta. Deshabilitar esa categoría detiene los mensajes.
El evento de la solicitud y la entrada de la bandeja de salida de notificaciones se confirman juntos. La entrega por Telegram usa una cola de reintentos y requiere un bot conectado. La página de seguimiento sigue siendo la fuente del estado actual si Telegram no está disponible o el bot está bloqueado.
La moderación recibe alertas separadas. Solo los usuarios en la lista de permitidos de moderación del servidor pueden limpiar una etapa desde Telegram; un botón antiguo no puede aplicar una decisión repetida. Los motivos de rechazo se editan en el espacio de trabajo de moderación.
Contrato de solicitud y decisión#
La propiedad proviene de la sesión. Los solicitantes no pueden enviar userId, estado, roles ni resultados de revisión. Repetir la creación con la misma Idempotency-Key y el mismo cuerpo devuelve la solicitud existente; cambiar el cuerpo con esa clave produce un conflicto.
Una decisión de moderador se aplica solo a la versión esperada de la solicitud. Las decisiones simultáneas se guardan una vez; la otra solicitud recibe 409. Un motivo de rechazo es texto plano de 10 a 1500 caracteres. La evidencia de revisión interna está restringida a los moderadores.
| Ruta | Acceso y comportamiento |
|---|---|
| POST /api/applications | Sesión + CSRF + Idempotency-Key; 202 con una URL privada |
| GET /api/applications | Solicitudes de la cuenta actual |
| GET /api/applications/{id} | Envío propio, etapas e historial público |
| POST /api/applications/{id}/resume | Sesión + CSRF; continúa solo las solicitudes en procesamiento |
| GET /api/moderation/applications | Solo moderadores verificados |
| POST /api/moderation/applications/{id}/decision | approve_step o reject, expectedVersion y un motivo de rechazo |
Después de la decisión#
Un nuevo pago e intento de tarjeta requieren que la última solicitud de revisión web del comerciante esté aprobada. La aprobación por sí sola no conecta la pasarela de pago. Si la revisión cambia después del envío, la operación existente permanece disponible para lecturas de estado, conciliación y un código bancario solicitado.
Si se rechaza, el comerciante ve el motivo y puede corregir los materiales antes de volver a solicitarlo. Una etapa amarilla significa que un especialista aún debe decidir; no es una aprobación automática.
Múltiples tiendas y un precio base en USD#
Elija Todas las tiendas para análisis y operaciones agregados, o seleccione una tienda para sus propios registros. Cada tienda tiene un storeId, nombre, IVA predeterminado, facturas, claves de API, endpoints de webhook, historial de eventos y aplicación web separados. Las notificaciones y tickets de soporte pertenecen a la cuenta. Una cuenta puede crear hasta 100 tiendas. Los registros existentes permanecen en su primera tienda.
Las facturas del nuevo espacio de trabajo usan pricingMode="universal" y un precio base en USD. Any incluye tarjeta, alipay, sbp y cripto; un comerciante puede seleccionar un subconjunto. Tarjetas y Alipay cobran en USD. SBP cobra en RUB usando el tipo de referencia USD/RUB del Banco de Rusia. Cripto cobra USDT bajo la regla explícita de factura 1 USD = 1 USDT. Esta es una regla de conversión de factura, no una cotización de mercado de USDT. La pasarela proporciona la tasa de la moneda seleccionada, el monto exacto de transferencia y las instrucciones antes de la transferencia.
El tipo de referencia y ambos montos se congelan al crear. Las facturas que implican conversión de RUB vencen dentro de 24 horas. Si no se puede obtener el tipo de referencia, la creación falla con FX_UNAVAILABLE; no se usa ningún tipo de respaldo inventado o desactualizado. El monto en minor del propietario y las cotizaciones usan la moneda contable USD. quotes[method].settlement contiene la cotización de cargo nativa. El checkout público expone la moneda de cargo seleccionada en currency, el precio original en baseAmountMinor/baseCurrency y el tipo de referencia en fx. Una vez que un pago ha sido despachado, su método no se puede cambiar; una factura tiene una operación de pasarela.
Cree una clave de API dentro de la tienda prevista y envíe Authorization: Bearer <key> desde su servidor. Su vinculación a tienda es inmutable; X-Kevmi-Store no puede otorgarle acceso a otra tienda. Las sesiones del navegador seleccionan X-Kevmi-Store: <storeId>; omitirlo selecciona la primera tienda. El valor all solo es aceptado por GET /api/account/dashboard y GET /api/payment-links. Las mutaciones requieren una tienda seleccionada, Origin y X-CSRF-Token. Los IDs de cuenta y los IDs de tienda son identificadores diferentes.
Por compatibilidad, las solicitudes de API sin pricingMode="universal" conservan el precio nativo y las restricciones de moneda originales. Las facturas existentes nunca se recalculan. Los recibos confirmados en análisis reflejan pagos verificados menos gastos de factura guardados; no son un saldo retirable. Las monedas de factura heredadas permanecen separadas y los pagos se gestionan con soporte. Cumpla un pedido solo después de verificar payment.fulfillmentReady=true y payment.status="succeeded" a través de la API del servidor, el historial de eventos o un webhook firmado.