Faire une demande pour connecter votre boutique
Soumettez votre site web après vous être connecté avec Telegram et suivez chaque étape de révision à une URL privée. Les vérifications automatisées aident le réviseur ; un modérateur prend toujours la décision finale.
Sur cette page
Soumettre une demande#
Les descriptions exigent 40 à 3000 caractères ; les noms de projet admettent jusqu'à 100. Le site web doit être accessible sans connexion. Les URL contenant des identifiants, des hôtes privés, des ports non standard ou des paramètres de requête ne sont pas acceptées.
Le compte vérifié possède la demande. Le contact Telegram saisi sert à la communication et ne change pas la propriété. Transférer l'URL de suivi n'accorde pas l'accès à un autre compte.
- 1
Connectez-vous ou inscrivez-vous avec Telegram, puis ouvrez /account#applications.
- 2
Saisissez une adresse de site web HTTPS publique, un nom de projet, une catégorie et une description de vos produits ou services.
- 3
Ajoutez un contact Telegram. Expliquez ce que les clients reçoivent et comment les commandes sont exécutées.
- 4
Confirmez votre autorité à soumettre le site et envoyez le formulaire.
- 5
Conservez l'adresse /account#applications/{id} qui s'ouvre immédiatement après la soumission.
Quatre étapes de révision#
La ligne de connexion et les marqueurs d'étape reflètent les états serveur persistés. Rouvrir la page poursuit le même processus. Fermer l'onglet n'annule pas votre demande ; les tâches en arrière-plan continuent de travailler et récupèrent les étapes interrompues.
| Étape | Ce qui se passe | Statut affiché |
|---|---|---|
| Demande reçue | Les détails de la soumission et l'URL privée sont enregistrés | La première étape est terminée |
| Examen du contenu | L'IA compare la description avec le contenu du site public | En cours, terminée ou en attente d'un spécialiste |
| Vérifications techniques | La disponibilité et un ensemble limité de liens sont examinés | Un résultat distinct et l'horodatage de l'étape |
| Examen du spécialiste | Un modérateur examine la soumission et les constatations | En attente de décision, approuvée ou un motif de refus |
Une étape jaune nécessite un spécialiste#
Un marqueur jaune signifie qu'une étape nécessite une attention, par exemple parce que les informations sont insuffisantes, qu'un lien est indisponible ou qu'un résultat automatisé ne peut pas être accepté avec confiance. Ce n'est pas un rejet définitif. La page de statut explique l'étape suivante.
Un modérateur peut effacer l'étape en cours pour que la vérification suivante se poursuive. Une étape refusée affiche une croix et un motif visible par l'utilisateur que le modérateur peut modifier avant l'envoi. Effacer une étape intermédiaire ne supprime jamais l'examen manuel final.
Ce que couvrent les vérifications automatisées#
Les vérifications examinent la page d'accueil publique : HTTPS, réponse HTTP, titre, texte et schémas de liens suspects. Elles demandent également des en-têtes pour au plus trois liens sur le même site. Le nombre de redirections, la taille de la réponse et le temps de requête sont limités.
Les vérifications n'accèdent pas aux zones connectées, n'exécutent pas de fichiers téléchargés et ne remplacent pas un audit de sécurité ou un scanner de logiciels malveillants. Terminer une étape ne garantit pas que chaque page est exempte de contenu malveillant.
Le contenu du site est une donnée non fiable. Les instructions présentes sur un site ne peuvent pas attribuer un administrateur, modifier les conditions Kevmi ni approuver une demande. Une IA indisponible et une sortie de modèle malformée nécessitent un examen par un spécialiste au lieu de passer silencieusement l'étape.
Mises à jour Telegram#
La réception d'une demande, la fin d'une étape, la demande d'attention d'un spécialiste et la prise d'une décision finale créent des notifications avec un lien de suivi privé. Celles-ci utilisent la catégorie Assistance dans les paramètres de notification du compte. Désactiver cette catégorie arrête les messages.
L'événement de demande et l'entrée de la boîte d'envoi de notification sont validés ensemble. La livraison Telegram utilise une file d'attente de réessai et nécessite un bot connecté. La page de suivi reste la source du statut actuel si Telegram est indisponible ou si le bot est bloqué.
La modération reçoit des alertes séparées. Seuls les utilisateurs figurant sur la liste blanche de modération du serveur peuvent effacer une étape depuis Telegram ; un ancien bouton ne peut pas appliquer une décision répétée. Les motifs de refus sont modifiés dans l'espace de travail de modération.
Contrat de demande et de décision#
La propriété provient de la session. Les candidats ne peuvent pas soumettre userId, le statut, les rôles ni les résultats d'examen. Répéter la création avec la même clé d'idempotence et le même corps renvoie la demande existante ; modifier le corps avec cette clé produit un conflit.
Une décision de modérateur s'applique uniquement à la version attendue de la demande. Les décisions simultanées sont enregistrées une fois ; l'autre requête reçoit un 409. Un motif de refus est un texte brut de 10 à 1500 caractères. Les preuves internes d'examen sont réservées aux modérateurs.
| Route | Accès et comportement |
|---|---|
| POST /api/applications | Session + CSRF + clé d'idempotence ; 202 avec une URL privée |
| GET /api/applications | Demandes du compte actuel |
| GET /api/applications/{id} | Soumission détenue, étapes et historique public |
| POST /api/applications/{id}/resume | Session + CSRF ; poursuit uniquement le traitement des demandes |
| GET /api/moderation/applications | Modérateurs vérifiés uniquement |
| POST /api/moderation/applications/{id}/decision | approve_step ou reject, expectedVersion et un motif de refus |
Après la décision#
Un nouveau paiement et une intention de carte nécessitent l'approbation de la dernière demande de revue du site du marchand. L'approbation seule ne connecte pas la passerelle de paiement. Si la revue change après l'envoi, l'opération existante reste disponible pour la lecture des statuts, le rapprochement et un code bancaire demandé.
En cas de refus, le marchand voit le motif et peut corriger les documents avant de présenter une nouvelle demande. Une étape jaune signifie qu'un spécialiste doit encore décider ; ce n'est pas une approbation automatique.
Plusieurs boutiques et un prix de base USD unique#
Choisissez Toutes les boutiques pour les analyses et opérations agrégées, ou sélectionnez une boutique pour ses propres enregistrements. Chaque boutique possède un storeId, un nom, une TVA par défaut, des factures, des clés API, des points de terminaison webhook, un historique d'événements et une application de site Web distincts. Les notifications et les tickets de support appartiennent au compte. Un compte peut créer jusqu'à 100 boutiques. Les enregistrements existants restent dans sa première boutique.
Les factures du nouvel espace de travail utilisent pricingMode="universal" et un prix de base en USD. Any inclut carte, alipay, sbp et crypto ; un commerçant peut sélectionner un sous-ensemble. Les cartes et Alipay facturent en USD. SBP facture en RUB en utilisant le taux de référence USD/RUB de la Banque de Russie. La crypto facture en USDT selon la règle de facturation explicite 1 USD = 1 USDT. Il s'agit d'une règle de conversion de facturation, pas d'une cotation USDT de marché. La passerelle fournit le taux de la pièce sélectionnée, le montant exact du transfert et les instructions avant le transfert.
Le taux de référence et les deux montants sont gelés à la création. Les factures impliquant une conversion RUB expirent dans les 24 heures. Si le taux de référence ne peut pas être obtenu, la création échoue avec FX_UNAVAILABLE ; aucun taux de secours inventé ou obsolète n'est utilisé. Le montant en monnaie mineure du propriétaire et les cotations utilisent la monnaie comptable USD. quotes[method].settlement contient la cotation de frais native. Le paiement public expose la monnaie de frais sélectionnée dans currency, le prix d'origine dans baseAmountMinor/baseCurrency, et le taux de référence dans fx. Une fois qu'un paiement a été envoyé, sa méthode ne peut pas être modifiée ; une facture a une seule opération de passerelle.
Créez une clé API dans la boutique prévue et envoyez Authorization: Bearer <key> depuis votre serveur. Sa liaison de boutique est immuable ; X-Kevmi-Store ne peut pas lui accorder l'accès à une autre boutique. Les sessions de navigateur sélectionnent X-Kevmi-Store: <storeId> ; si omis, la première boutique est sélectionnée. La valeur all n'est acceptée que par GET /api/account/dashboard et GET /api/payment-links. Les mutations nécessitent une boutique sélectionnée, Origin et X-CSRF-Token. Les identifiants de compte et les identifiants de boutique sont des identifiants différents.
Pour la compatibilité, les demandes API sans pricingMode="universal" conservent la tarification native et les restrictions de monnaie d'origine. Les factures existantes ne sont jamais recalculées. Les reçus confirmés dans les analyses reflètent les paiements vérifiés moins les dépenses de facture enregistrées ; ils ne constituent pas un solde retirable. Les monnaies de facture héritées restent séparées et les paiements sont organisés avec le support. Exécutez une commande uniquement après avoir vérifié payment.fulfillmentReady=true et payment.status="succeeded" via l'API serveur, l'historique d'événements ou un webhook signé.