Connecter une boutique

« Connecter à Tallio » est une autorisation OAuth 2.0 par code d’autorisation (authorization code) avec PKCE (S256). Le code transite par le navigateur ; le vérificateur ne quitte jamais le serveur de la boutique, si bien qu’un code seul est inutilisable.

• Demande. La boutique conserve un state aléatoire et un code_verifier (43 à 128 caractères), et envoie le navigateur de son administrateur vers la page hébergée de Tallio avec le challenge. redirect_uri doit être exactement le callback de la boutique sous son URL, rien d’autre.
• Consentement. L’administrateur se connecte à Tallio, ou s’inscrit, et un propriétaire de l’équipe approuve la boutique, en confirmant avec un second facteur ou une nouvelle connexion. Lors d’une première connexion, il saisit aussi les identifiants fiscaux de l’entreprise, et Tallio crée son marchand.
• Retour. Le navigateur revient sur redirect_uri avec code et le même state, ou avec error=access_denied si l’administrateur annule. Le code est valable 10 minutes.
• Échange. Le serveur de la boutique appelle POST /store_grants/token avec le code, le vérificateur et le même redirect_uri, en se nommant dans Tallio-Store-Url. La réponse, donnée une seule fois, contient le marchand, l’équipe, les deux clés et les secrets des endpoints de webhook de la boutique.

Tout échange refusé reçoit le même 400 invalid_grant, quelle qu’en soit la cause. Ne refaites jamais un échange réussi : échanger à nouveau un code déjà utilisé avec son vérificateur révoque les clés qu’il a produites, puisqu’un rejeu signifie que le code a fuité. Après une réponse perdue, recommencez la connexion de la boutique.

Passez la langue de l’administrateur dans locale (el, fr_FR, en_US) : la connexion et la page de consentement la suivent quand Tallio la parle, pour cette session uniquement. Une valeur inconnue ou absente ne fait jamais refuser la requête.

L’échange renvoie toujours une clé de test, et une clé live uniquement pour une boutique de production. Envoyez store_environment (production, staging, development, local) : toute valeur autre que production n’obtient qu’une clé de test, tout comme un hôte de développement (localhost, .test, une adresse privée, un tunnel public). Une clé de test émet via la connexion de test du marchand, ou via la sandbox de Tallio s’il n’y en a pas.

Les clés d’une boutique sont liées à son URL. Envoyez-la dans Tallio-Store-Url à chaque appel : une autre valeur, ou aucune, donne 409 store_url_mismatch. Cela empêche une copie de préproduction de la boutique d’émettre en live avec des paramètres copiés ; ce n’est pas un secret. Quand la boutique a réellement changé d’URL, son administrateur confirme le déplacement et la boutique envoie sa nouvelle URL à PUT /store_binding ; tant que la boutique a une clé live, seule cette clé peut la déplacer.

Une clé de boutique n’atteint que les opérations du tableau ci-dessous, et uniquement pour son propre marchand : les ids d’un autre marchand répondent 404, comme s’ils n’existaient pas. Toute autre opération donne 403 restricted_key : une clé de boutique ne peut pas créer de marchands, lister les événements, gérer les endpoints de webhook ou les clés, ni atteindre le serveur MCP.

Quand la boutique se déconnecte ou que l’extension est supprimée, la boutique renonce à chaque clé avec DELETE /api_keys/current. Un propriétaire de l’équipe peut aussi révoquer les clés de la boutique depuis le tableau de bord ; une nouvelle connexion remplace les anciennes clés.