Candidate-se para conectar sua loja

Envie uma candidatura#

As descrições exigem 40–3000 caracteres; os nomes de projeto permitem até 100. O site deve ser acessível sem fazer login. URLs contendo credenciais, hosts privados, portas não padrão ou parâmetros de consulta não são aceitas.

A conta verificada é a proprietária da candidatura. O contato Telegram informado é para comunicação e não muda a propriedade. Encaminhar a URL de rastreamento não concede acesso a outra conta.

1. 1

   Entre ou registre-se com Telegram e depois abra /account#applications.

2. 2

   Informe um endereço de site HTTPS público, nome do projeto, categoria e uma descrição dos seus produtos ou serviços.

3. 3

   Adicione um contato Telegram. Explique o que os clientes recebem e como os pedidos são atendidos.

4. 4

   Confirme sua autoridade para enviar o site e envie o formulário.

5. 5

   Guarde o endereço /account#applications/{id} que abre imediatamente após o envio.

Quatro etapas de revisão#

A linha de conexão e os marcadores de etapa refletem estados persistidos no servidor. Reabrir a página continua o mesmo processo. Fechar a aba não cancela sua candidatura; trabalhos em segundo plano continuam funcionando e recuperam etapas interrompidas.

Uma etapa amarela precisa de um especialista#

Um marcador amarelo significa que uma etapa precisa de atenção, por exemplo porque as informações são insuficientes, um link está indisponível ou um resultado automatizado não pode ser aceito com confiança. Não é uma rejeição final. A página de status explica o próximo passo.

Um moderador pode limpar a etapa atual para que a próxima verificação continue. Uma etapa recusada exibe uma cruz e um motivo visível ao usuário que o moderador pode editar antes de enviar. Limpar uma etapa intermediária nunca remove a revisão manual final.

O que as verificações automatizadas cobrem#

As verificações examinam a página inicial pública: HTTPS, resposta HTTP, título, texto e padrões suspeitos de links. Elas também solicitam cabeçalhos de no máximo três links no mesmo site. A contagem de redirecionamentos, o tamanho da resposta e o tempo de solicitação são limitados.

As verificações não acessam áreas autenticadas, não executam arquivos baixados nem substituem uma auditoria de segurança ou um scanner de malware. Concluir uma etapa não garante que toda página esteja livre de conteúdo malicioso.

O conteúdo do site são dados não confiáveis. Instruções em um site não podem designar um administrador, alterar os termos da Kevmi nem aprovar uma solicitação. IA indisponível e saída de modelo malformada exigem revisão do especialista em vez de passar pela etapa silenciosamente.

Atualizações do Telegram#

Receber uma solicitação, concluir uma etapa, solicitar atenção do especialista e tomar uma decisão final criam notificações com um link de rastreamento privado. Elas usam a categoria Suporte nas configurações de notificação da conta. Desativar essa categoria interrompe as mensagens.

O evento da solicitação e a entrada da caixa de saída de notificações são confirmados juntos. A entrega via Telegram usa uma fila de tentativas e exige um bot conectado. A página de rastreamento permanece a fonte do status atual se o Telegram estiver indisponível ou o bot estiver bloqueado.

A moderação recebe alertas separados. Somente usuários na lista de permissão de moderadores do servidor podem limpar uma etapa pelo Telegram; um botão antigo não pode aplicar uma decisão repetida. Os motivos de recusa são editados no espaço de trabalho da moderação.

Contrato de solicitação e decisão#

A propriedade vem da sessão. Os candidatos não podem enviar userId, status, papéis ou resultados de revisão. Repetir a criação com o mesmo Idempotency-Key e corpo retorna a solicitação existente; alterar o corpo com essa chave produz um conflito.

Uma decisão de moderador se aplica apenas à versão esperada da solicitação. Decisões simultâneas são salvas uma vez; a outra solicitação recebe 409. Um motivo de recusa é texto simples de 10–1500 caracteres. As evidências internas de revisão são restritas aos moderadores.

Após a decisão#

Um novo pagamento e uma intenção de cartão exigem que a solicitação mais recente de revisão do site do comerciante seja aprovada. A aprovação por si só não conecta o gateway de pagamento. Se a revisão mudar após o envio, a operação existente permanece disponível para leitura de status, conciliação e um código bancário solicitado.

Se rejeitado, o comerciante vê o motivo e pode corrigir os materiais antes de se candidatar novamente. Uma etapa amarela significa que um especialista ainda precisa decidir; não é aprovação automática.

Múltiplas lojas e um preço base em USD#

Escolha Todas as lojas para análises e operações agregadas, ou selecione uma loja para seus próprios registros. Cada loja tem um storeId separado, nome, padrão de IVA, faturas, chaves de API, endpoints de webhook, histórico de eventos e aplicativo de site. Notificações e tickets de suporte pertencem à conta. Uma conta pode criar até 100 lojas. Registros existentes permanecem na primeira loja.

As faturas do novo workspace usam pricingMode="universal" e um preço base em USD. O plano Any inclui cartão, alipay, sbp e cripto; um comerciante pode selecionar um subconjunto. Cartões e Alipay cobram em USD. O SBP cobra em RUB usando a taxa de referência USD/RUB do Banco da Rússia. Cripto cobra USDT sob a regra explícita de fatura 1 USD = 1 USDT. Esta é uma regra de conversão de fatura, não uma cotação de mercado de USDT. O gateway fornece a taxa da moeda selecionada, o valor exato da transferência e instruções antes da transferência.

A taxa de referência e ambos os valores são congelados na criação. Faturas que envolvem conversão RUB expiram dentro de 24 horas. Se a taxa de referência não puder ser obtida, a criação falha com FX_UNAVAILABLE; nenhuma taxa de fallback inventada ou desatualizada é usada. O valor do proprietário em minor e cotações usam a moeda contábil USD. quotes[method].settlement contém a cotação de cobrança nativa. O checkout público expõe a moeda de cobrança selecionada em currency, o preço original em baseAmountMinor/baseCurrency, e a taxa de referência em fx. Uma vez que um pagamento foi enviado, seu método não pode ser alterado; uma fatura tem uma operação de gateway.

Crie uma chave de API dentro da loja pretendida e envie Authorization: Bearer <key> do seu servidor. Seu vínculo de loja é imutável; X-Kevmi-Store não pode conceder acesso a outra loja. Sessões de navegador selecionam X-Kevmi-Store: <storeId>; omitir seleciona a primeira loja. O valor all é aceito apenas por GET /api/account/dashboard e GET /api/payment-links. Mutações exigem uma loja selecionada, Origin e X-CSRF-Token. IDs de conta e IDs de loja são identificadores diferentes.

Para compatibilidade, solicitações de API sem pricingMode="universal" mantêm preço nativo e as restrições originais de moeda. Faturas existentes nunca são recalculadas. Recibos confirmados nas análises refletem pagamentos verificados menos despesas de fatura salvas; eles não são um saldo sacável. Moedas de fatura legadas permanecem separadas e pagamentos são combinados com o suporte. Cumpra um pedido somente após verificar payment.fulfillmentReady=true e payment.status="succeeded" através da API do servidor, histórico de eventos ou um webhook assinado.