Como funciona na prática a integração RFID da Hubject (um passo a passo em 5 etapas)

Se você gerencia uma rede de Operadores de Pontos de Recarga (CPO) ou é um Provedor de Serviços de Mobilidade Elétrica (eMSP) e deseja que os cartões dos seus clientes funcionem fora do seu território de origem, você precisará se integrar ao Hubject. A maioria dos operadores com quem trabalhamos nos procura depois de já ter assinado com o Hubject, quando se depara com a especificação OICP tentando entender o que o cartão em si precisa fazer.

Este é um guia prático: o que acontece entre a aproximação do cartão pelo motorista e o início de uma sessão de recarga, onde o seu fornecedor de cartões se posiciona nessa cadeia e os detalhes específicos que determinam se a leitura do cartão realmente terá sucesso.

O Fluxo em 5 Etapas

Quando um motorista seu aproxima um cartão RFID em um carregador com roaming Hubject na rede de outro CPO, é isto o que acontece:

1.Aproximação do cartão.: O motorista apresenta o cartão ao leitor de cartões RFID do carregador. O leitor extrai o UID do chip — o identificador exclusivo definido de fábrica, de 4 ou 7 bytes, dependendo da família do chip.

2.O CPO envia o UID para o Hubject.: O backend do CPO anfitrião não sabe a quem este cartão pertence. Ele empacota o UID em uma requisição OICP AuthorizeStart e a encaminha para o Hubject. A requisição inclui o ID do próprio CPO, o EVSE ID (o ponto de recarga específico) e o UID.

3.O Hubject encaminha o UID para o seu backend.: O Hubject atua como a câmara de compensação: ele sabe que este UID pertence ao seu eMSP com base nos mapeamentos de EvcoIDs OICP e IDs de provedor que você registrou. Ele encaminha a requisição de autorização para o endpoint do seu CPO/eMSP.

4.Seu backend autoriza (ou rejeita).: Seu backend busca o UID no seu banco de dados de usuários, verifica se a conta está ativa e regular, opcionalmente aplica quaisquer regras de tarifas e retorna uma decisão de autorização — Autorizado com o ID do contrato, ou NãoAutorizado com um código de motivo.

5.O Hubject confirma de volta para o CPO.: O CPO anfitrião recebe a autorização, o carregador é desbloqueado e a sessão começa. Os dados de recarga e o faturamento final são liquidados através do Hubject após o término da sessão.

Toda essa cadeia normalmente é concluída em menos de um segundo. Quando ocorre uma falha, quase sempre é em um de dois pontos: o formato do UID no seu cartão não corresponde ao que o seu backend espera, ou os mapeamentos de ID de provedor na sua conta Hubject não incluem a faixa de chips que você está emitindo.

O Que o Cartão em Si Precisa Fazer

O papel do cartão neste fluxo é pequeno, mas específico: apresentar um UID que o seu backend reconheça. Isso parece trivial até você começar a emitir cartões de múltiplas famílias de chips e notar que o comprimento da chave do seu banco de dados está configurado de forma rígida (hardcoded).

Algumas decisões precisam ser tomadas antes do envio do primeiro lote:

•

Comprimento do UID.: O MIFARE Classic retorna um UID de 4 bytes. O Ultralight EV1 e o DESFire EV2/EV3 retornam UIDs de 7 bytes. A especificação OICP 2.3 do Hubject aceita UIDs de 4 e 7 bytes (bem como de 10 bytes), portanto a escolha não o bloqueia no hub de roaming — mas a coluna do seu próprio banco de dados de backend precisa ser larga o suficiente para armazenar o formato que você escolher. Se você pretende misturar famílias de chips no futuro (um cartão básico no Ultralight EV1, um cartão de frota premium no DESFire), use um VARCHAR(20) ou equivalente e normalize para strings hexadecimais.

•

Mapeamento de UID para cliente.: Quando fabricamos um lote de produção, entregamos um arquivo CSV que mapeia o UID de cada cartão a um número de cartão voltado ao cliente (ou ID sequencial, ou qualquer campo que você especificar). Esse mapeamento é o que você carrega no seu banco de dados de usuários antes de ativar os cartões. Sem isso, você teria que ler fisicamente cada cartão para alimentar seu banco de dados — algo inviável em volumes de produção. Entregamos este CSV sem custo adicional.

•

Personalização.: O número do cartão voltado ao cliente é o que sua equipe de atendimento solicitará que o motorista leia quando ele ligar para o suporte. Podemos gravar a laser ou imprimir esse número no próprio cartão. Especificamente para recarga de veículos elétricos, a gravação a laser é mais durável do que a impressão — o cartão passa anos em carteiras e bolsos.

•

Pré-configuração.: Alguns operadores desejam que o cartão seja enviado com chaves criptográficas já carregadas para uma aplicação específica. Nós cuidamos disso no lote de produção; você fornece as chaves e os IDs das aplicações, e nós os provisionamos em cada cartão antes da personalização. Isso é mais relevante para implantações com DESFire do que com Ultralight EV1.

Modos de Falha Comuns (e Como Evitá-los)

Uma breve lista de problemas de integração que já observamos:

•

O formato do UID do cartão não corresponde ao backend.: Solução: confirme 4 bytes vs. 7 bytes antes do primeiro lote de produção e não confie apenas na documentação — aproxime fisicamente uma amostra no seu backend de teste antes de fazer o pedido.

•

A faixa de UIDs não está registrada no Hubject sob o seu ID de provedor.: Solução: registre a faixa de UIDs dos chips no seu portal Hubject antes de entrar em operação, não depois.

•

Tempo de resposta de autorização muito lento.: Solução: na maioria das vezes, trata-se de um problema de latência no backend, não no cartão. A comunicação inicial entre o cartão e o carregador é rápida. Se você estiver enfrentando atrasos superiores a 3 segundos, analise o tempo de resposta do backend do seu CPO/eMSP.

•

Os clientes recebem os cartões, mas eles não aparecem no banco de dados de usuários.: Solução: carregue o CSV de mapeamento de UID para cliente no seu banco de dados *antes* de enviar os cartões para os usuários finais. Parece óbvio, mas é algo que atrapalha a maioria dos operadores em seu primeiro lote.

O Que Especificar ao Solicitar Seus Cartões

Se você está prestes a definir o escopo de um pedido de cartões conosco (ou com qualquer fornecedor de cartões), a folha de especificações que torna a integração com o Hubject simples e sem complicações deve conter:

•Família do chip (Ultralight EV1 / DESFire — consulte o nosso guia de chips para fazer a escolha)

•Comprimento do UID que você deseja que seja retornado (legado de 4 bytes / padrão de 7 bytes)

•Se você precisa de aplicações DESFire pré-provisionadas (e as chaves, se for o caso)

•O formato CSV que você deseja para o mapeamento de UID para número do cliente (ordem das colunas, separador, codificação)

•Se o número voltado ao cliente deve ser gravado a laser, impresso ou ambos

Acerte esses cinco pontos e o fluxo do Hubject se tornará um exercício de configuração, em vez de um exercício de depuração de erros.

Próximos Passos

Se você está na fase de comparar famílias de chips antes de se comprometer, leia Qual chip RFID é o ideal para recarga de veículos elétricos? para entender a abordagem que sugerimos. Se você já conhece o chip e quer ver um pessoalmente, solicite um kit de amostras — enviamos amostras de Ultralight EV1, DESFire e PVC reciclado de uma só vez, e sua equipe de desenvolvimento poderá ler os UIDs em seu ambiente de teste do Hubject antes de qualquer compromisso de compra.

Ou fale conosco sobre o seu projeto de integração — preferência de chip, volume estimado, hub de roaming, país de implantação — e retornaremos com uma especificação técnica viável e o formato de CSV pronto para ser integrado ao seu backend.

Como funciona na prática a integração RFID da Hubject (um passo a passo em 5 etapas)

O Fluxo em 5 Etapas

O Que o Cartão em Si Precisa Fazer

Modos de Falha Comuns (e Como Evitá-los)

O Que Especificar ao Solicitar Seus Cartões

Próximos Passos

Pronto para tornar a sua rede de recarga mais ecológica?

Artigos Relacionados

Transparência de Preços e Dados da AFIR para 2026: O que a DATEX II Significa para o RFID e o Roaming

Conformidade com o AFIR 2026: Prazos de Recarga de VE e Checklist de RFID