Dépannage EMSP : un badge en itinérance ne fonctionne pas

« J'ai activé le badge, mais il ne marche pas sur la borne. » Cette page vous aide à trouver la cause quand un de vos badges, utilisé en itinérance sur la borne d'un opérateur partenaire (CPO), ne démarre pas la recharge.

Elle concerne les deux modes de connexion :

via une plateforme d'itinérance (roaming hub) comme Gireve (voir Connexion Gireve EMSP) ou Hubject ;
via une connexion peer-to-peer OCPI directe avec le CPO (voir Connexion peer-to-peer).

Le principe à retenir

Quand votre client présente son badge sur la borne d'un partenaire, ce n'est pas Chargekeeper qui pilote la borne : c'est la supervision du CPO. Pour savoir si le badge a le droit de charger, le CPO envoie une demande d'autorisation OCPI (Authorize) à votre plateforme. Chargekeeper répond « autorisé » ou « refusé ».

Si cette demande n'arrive jamais chez nous, Chargekeeper ne peut rien autoriser, quel que soit le paramétrage du badge, de l'utilisateur ou du tarif.

Une chaîne longue, dont Chargekeeper n'est que le dernier maillon

Pour que la demande d'autorisation nous parvienne via une plateforme d'itinérance, chaque maillon doit fonctionner :

la borne du partenaire est connectée et communique avec sa supervision — qui n'est pas Chargekeeper ;
la supervision du CPO communique correctement en OCPI avec la plateforme d'itinérance (Gireve, Hubject…) ;
la plateforme d'itinérance transmet la demande vers Chargekeeper.

En peer-to-peer, la chaîne est plus courte : la supervision du CPO nous appelle directement, sans intermédiaire.

Le parcours d'une demande d'autorisation : badge, borne du partenaire, supervision du CPO, plateforme d'itinérance, puis Chargekeeper en EMSP, qui répond autorisé ou refusé

Le diagnostic commence donc toujours par la même question :

La demande d'autorisation pour ce badge est-elle arrivée chez nous, au moment de l'essai ?

Non → le problème se situe en amont de Chargekeeper. Voir Étape 1.
Oui, et elle a été refusée → le problème vient du paramétrage dans Chargekeeper. Voir Étape 2.

Arbre de diagnostic : si la demande n'apparaît pas dans les logs, le problème est en amont ; si elle apparaît, Chargekeeper a refusé et il faut corriger le paramétrage

Étape 1 : la demande d'autorisation arrive-t-elle chez nous ?

Notez l'heure exacte de l'essai, l'identifiant du badge et la borne utilisée (opérateur, adresse, identifiant EVSE si possible).

Ce que vous pouvez vérifier dans Chargekeeper

Ouvrez les Logs et recherchez l'identifiant du badge autour de l'heure de l'essai. Les demandes d'autorisation en itinérance sont journalisées sous l'action OcpiEmspAuthorizeToken.

Chaque refus est journalisé. Un refus apparaît sous la forme :

Roaming authorization refused for Tag ID '<badge>' on Charging Station '<borne>': <raison>

ou sous la forme d'une erreur sur la même action (badge inconnu, borne inconnue, aucun tarif applicable…). Si vous trouvez une telle ligne, la demande est bien arrivée : passez à l'Étape 2.

Si vous ne trouvez aucune ligne pour ce badge à l'heure de l'essai, et qu'aucune session n'apparaît dans Sessions › Sessions sur bornes partenaires CPO, la demande n'est vraisemblablement jamais arrivée jusqu'à Chargekeeper.

Une autorisation acceptée ne produit pas toujours de ligne visible dans les logs. L'absence de ligne ne prouve donc pas à elle seule que rien n'est arrivé : croisez-la avec la liste des sessions sur bornes partenaires.

Premier réflexe : interroger votre plateforme d'itinérance

Via une plateforme d'itinérance, il est rarement possible de joindre directement l'opérateur de la borne. Le premier interlocuteur est donc votre plateforme d'itinérance (Gireve, Hubject…). Ouvrez un ticket chez elle (Mantis pour Gireve) en donnant l'heure de l'essai, l'identifiant du badge et la borne, et demandez-lui de confirmer :

que sa liaison vers votre plateforme Chargekeeper fonctionne dans le sens descendant, c'est-à-dire qu'elle nous transmet bien les demandes d'autorisation ;
qu'elle a bien reçu une demande d'autorisation du CPO pour ce badge, et ce qu'elle en a fait ;
que vos badges sont connus de la plateforme : après l'import dans Chargekeeper, Gireve doit les intégrer de son côté.

Vos badges sont-ils connus du partenaire ?

Chargekeeper peut transmettre la liste de vos badges à vos partenaires CPO, en peer-to-peer comme via une plateforme d'itinérance :

automatiquement, quand la connexion d'itinérance est enregistrée et que son processus de mise à jour automatique est activé ;
à la demande, avec l'action Envoyer les badges sur la connexion d'itinérance.

Chaque badge est transmis avec son état : il n'est déclaré valide que s'il est actif, que l'itinérance y est activée et que son utilisateur est actif. Les envois sont journalisés sous l'action OcpiEmspUpdateTokens.

Cette liste permet au CPO de reconnaître vos badges, mais ne le dispense pas de nous interroger : Chargekeeper transmet ses badges en demandant une autorisation en temps réel à chaque recharge (liste blanche OCPI NEVER). Chaque recharge passe donc quand même par une demande d'autorisation vers Chargekeeper, et le principe de cette page reste valable.

Si le partenaire ne reconnaît pas un badge, relancez Envoyer les badges, puis demandez-lui de confirmer qu'il l'a bien reçu.

Deuxième vérification : un accord d'itinérance signé avec ce CPO

Une connexion technique qui fonctionne ne suffit pas. Sur une plateforme d'itinérance, vos clients ne peuvent charger sur les bornes d'un CPO que si un accord d'itinérance a été signé entre vous, en tant qu'EMSP, et ce CPO précis : celui qui exploite la borne sur laquelle l'essai a eu lieu. Selon la plateforme, cet accord s'appelle offre, contrat, accord ou agrément. Chez Gireve, ce sont les offres signées sur la Connect Place.

Vérifiez donc, sur la plateforme d'itinérance ou auprès d'elle :

quel opérateur (CPO) exploite la borne utilisée pour l'essai ;
qu'un accord est signé et en vigueur entre vous et cet opérateur ;
que cet accord couvre bien la borne utilisée pour l'essai.

Un badge qui fonctionne chez un CPO et pas chez un autre est très souvent le signe d'un accord manquant avec le second.

Si rien n'arrive malgré tout

Si la plateforme d'itinérance n'a reçu aucune demande du CPO, le problème se situe entre la borne, sa supervision et la plateforme : c'est à la plateforme d'itinérance de le remonter à l'opérateur.

En peer-to-peer

Le CPO est votre interlocuteur direct :

vérifiez que la connexion est active avec Tester la connexion dans le paramétrage de la connexion d'itinérance ;
demandez au CPO de confirmer que sa supervision a bien envoyé une demande d'autorisation vers votre plateforme, et quelle réponse elle a obtenue ;
vérifiez avec lui que vos badges figurent bien dans sa liste.

Étape 2 : la demande est arrivée mais a été refusée

Si une demande d'autorisation apparaît dans les logs, c'est une bonne nouvelle : toute la chaîne de communication fonctionne, de la borne du partenaire jusqu'à Chargekeeper, en passant par sa supervision et la plateforme d'itinérance. Il reste alors à comprendre pourquoi Chargekeeper a refusé.

Les trois vérifications à faire en premier

Dans la grande majorité des cas, le refus vient de l'un de ces trois points :

Le badge a-t-il l'option itinérance activée ? Dans la fiche du badge, l'option Itinérance activée (EMSP) doit être cochée, et le badge doit être actif.
L'utilisateur rattaché au badge est-il autorisé à charger ? Le badge doit être associé à un utilisateur, dont le compte est actif, et un tarif EMSP doit autoriser ce badge ou cet utilisateur au moment de l'essai.
Les recharges de l'utilisateur sont-elles payées ? Soit par un moyen de paiement personnel valide, soit par un contrat B2B de son entreprise. Voir ci-dessous.

Moyen de paiement personnel ou contrat B2B

Quand la facturation des recharges est activée et que la recharge n'est pas gratuite pour cet utilisateur, Chargekeeper vérifie que la recharge sera payée. Cela ne passe pas forcément par la carte de l'utilisateur : si son entreprise est couverte par un contrat B2B, c'est ce contrat qui règle les recharges.

Contrat en « Paiement mensuel (virement) » : aucun moyen de paiement n'est demandé à l'utilisateur. L'entreprise est facturée chaque mois.
Contrat en « Paiement à la charge (CB) » : c'est la carte du compte de facturation de l'entreprise qui est vérifiée, et non celle de l'utilisateur.
Aucun contrat B2B applicable : l'utilisateur doit avoir son propre moyen de paiement valide. Une carte absente ou expirée suffit à faire refuser la recharge.

Pour qu'un contrat B2B couvre une recharge en itinérance, vérifiez que :

l'utilisateur est bien rattaché à l'entreprise cliente du contrat ;
le contrat est conclu entre cette entreprise et l'une de vos entreprises opératrices (CPO) : la borne du partenaire n'appartient pas à vos entreprises, c'est donc votre propre entreprise qui sert de fournisseur ;
le contrat comprend la facturation des recharges ;
le contrat est en vigueur à la date de la recharge.

Les logs indiquent le contrat retenu pour la recharge, sous l'action BillingTransaction : User's company (…) has a Monthly (no credit card required) contract …, … has a PerRecharge (credit card required) contract … ou … has no contract ….

Toutes les raisons de refus

La ligne de log indique la raison exacte du refus. Voici toutes les raisons possibles et ce qu'il faut corriger.

Chargekeeper déroule ses contrôles dans l'ordre ci-dessous ; le premier qui échoue donne la raison du refus.

Les six contrôles de Chargekeeper dans l'ordre : borne connue, badge, utilisateur, restrictions, tarif EMSP, paiement

Raison dans les logs	Ce que cela signifie	Que faire
`Unknown Tag ID '…'`	Le badge n'existe pas dans Chargekeeper.	Vérifiez l'identifiant exact du badge (casse, zéros, format) et qu'il a bien été créé dans Badges.
`Charging Station with EVSE ID '…' and Location ID '…' does not exist`	La borne du partenaire n'est pas connue de Chargekeeper.	Récupérez les sites du partenaire : dans le paramétrage de la connexion d'itinérance, lancez Récupérer les sites, puis réessayez.
`Roaming is not enabled for the tag '…'`	L'itinérance n'est pas activée sur ce badge.	Dans la fiche du badge, cochez Itinérance activée (EMSP).
`Tag '…' is not active.`	Le badge est désactivé.	Activez le badge dans sa fiche.
`Tag '…' is not owned by the EMSP`	Le badge n'est pas l'un de vos badges, c'est le badge d'un partenaire.	Un badge partenaire ne peut pas être autorisé en tant qu'EMSP : utilisez l'un de vos propres badges.
`Unknown User for OCPI Token ID '…'`	Le badge n'est associé à aucun utilisateur.	Associez le badge à un utilisateur.
`user account status is '…'`	Le compte de l'utilisateur n'est pas actif (en attente, inactif, bloqué…).	Activez le compte de l'utilisateur. S'il est bloqué, vérifiez d'abord pourquoi (impayé, blocage manuel).
`charge point is located in blocked country '…'`	La connexion d'itinérance interdit le pays dans lequel se trouve la borne.	Vérifiez les pays bloqués dans le paramétrage de la connexion. Selon ce paramétrage, la tentative peut aussi avoir bloqué le compte de l'utilisateur.
`… roaming session(s) already in progress, limit is 1`	L'utilisateur a déjà une session d'itinérance en cours.	Une seule session d'itinérance est permise à la fois par utilisateur. Une session restée ouverte (le partenaire n'a jamais envoyé sa fin) bloque les suivantes : vérifiez Sessions sur bornes partenaires CPO et contactez le partenaire pour qu'il la clôture.
`… no pricing applies at this time!`	Aucun tarif EMSP ne couvre ce badge sur cette borne, à cette heure.	Créez ou corrigez un tarif EMSP applicable à ce badge ou à cet utilisateur. Vérifiez aussi ses dates de validité et ses plages de jours et d'heures.
`no valid payment method`	Ni l'utilisateur ni un contrat B2B de son entreprise ne couvrent le paiement.	Vérifiez d'abord si l'utilisateur doit être couvert par un contrat B2B (voir ci-dessus). Sinon, il doit enregistrer un moyen de paiement valide. En « Paiement à la charge (CB) », c'est la carte du compte de facturation de l'entreprise qui doit être valide.

Récapitulatif

Avant qu'une recharge en itinérance puisse être acceptée, il faut :

que la demande d'autorisation du CPO arrive chez Chargekeeper : borne connectée à sa supervision, supervision connectée à la plateforme d'itinérance, plateforme connectée à Chargekeeper (ou connexion peer-to-peer active) ;
que vos badges soient connus du partenaire (envoi des badges) ;
qu'un accord d'itinérance soit signé entre vous et le CPO qui exploite la borne (offre, contrat, accord ou agrément selon la plateforme) ;
que la borne du partenaire soit connue de Chargekeeper (sites récupérés) ;
que le badge existe, soit actif et ait l'itinérance activée ;
que le badge soit associé à un utilisateur actif ;
que le pays de la borne ne soit pas bloqué sur la connexion ;
que l'utilisateur n'ait pas déjà une session d'itinérance en cours ;
qu'un tarif EMSP s'applique à ce moment-là ;
que la recharge soit payée : par un moyen de paiement valide de l'utilisateur, ou par un contrat B2B de son entreprise.

Si tout est en ordre et que le refus persiste, contactez notre support en indiquant l'heure de l'essai, l'identifiant du badge, la borne, et le résultat de l'étape 1.