Rumo a duas estrelas do norte!
Melhorar as experiências de pagamento, tornando mais fácil para todos pagarem e facilitando para aqueles que recebem pagamentos em diferentes regiões geográficas, tem sido o cerne do que a Juspay representa há mais de uma década. Algumas das escolhas tecnológicas que fizemos para possibilitar isso nos levaram a construir um dos softwares de pagamento mais utilizados. Há uma década, smartphones e conectividade à internet estavam em um ponto de inflexão. Apostamos nessa tendência cedo. Percebemos que as melhores experiências de pagamento aconteceriam em telefones e, para melhorar a experiência do usuário, tínhamos que executar software em dispositivos de borda.
Para fazer isso, construímos um Kit de Desenvolvimento de Software (SDK) que simplifica o processo de integração para os comerciantes, ao mesmo tempo em que garante uma experiência de pagamento fluída para os usuários finais. Este blog mergulha na arquitetura do nosso SDK, nos desafios que enfrentamos e nas soluções inovadoras que implementamos para tornar os pagamentos mais rápidos e eficientes. Os SDKs da Juspay são ferramentas essenciais que ajudam os aplicativos dos comerciantes a interagir com nossa Camada de Orquestração. É como se fosse um funcionário interno da Juspay, realizando o trabalho para o comerciante da página de checkout até o final da jornada de compra. Desde os primeiros dias da construção de um SDK até hoje, trabalhamos com duas estrelas do norte: Performance e Adoção. A página de pagamento é um terreno fértil para pequenas mudanças que podem impulsionar os objetivos das empresas. Como garantir que os usuários vejam a página de pagamento certa, mas também não esperem que os ativos certos sejam baixados todas as vezes, é A questão que tentamos responder em cada iteração do SDK.
Primeiro: Por que precisamos de um SDK?
As empresas que integram soluções de pagamento geralmente enfrentam uma tarefa difícil: integrar várias APIs, cada uma lidando com diferentes aspectos do fluxo de pagamento. Isso não apenas aumenta o tempo de desenvolvimento, mas também introduz complexidades e potenciais pontos de falha. Para resolver isso, decidimos criar um SDK (kit de desenvolvimento de software) que atuasse como uma solução plug-and-play, abstraindo complexidades e permitindo que os comerciantes operem rapidamente.
O SDK é um trecho de código que reside dentro do aplicativo do comerciante quando ele se integra à Juspay. Nosso SDK é projetado para lidar com tudo, desde o processamento de pagamentos até a renderização da interface do usuário, garantindo que os comerciantes não precisem se preocupar em integrar 25 APIs diferentes. Em vez disso, ele utuliza um único SDK que faz tudo.
A Arquitetura: SDK Nativo + Camada JavaScript
Em sua essência, nossos SDKs são construídos em uma arquitetura de duas camadas: uma camada nativa e outra a JavaScript.
A Camada Nativa
A camada nativa é a base do SDK. É leve, pesando apenas 300-350 KB, e lida com operações básicas como:
- Chamadas de rede: Fazer requisições à internet para processar pagamentos.
- Operações do sistema de arquivos: Baixar, atualizar e remover arquivos.
- Registro (Logging): Escrever logs no sistema de arquivos do dispositivo.
- Renderização: Renderizar a interface do usuário para os diferentes fluxos e plataformas de pagamento (Android / iOS / Web).
A camada nativa é mantida minimalista para garantir desempenho e eficiência.
A Camada JavaScript
Acima da camada nativa reside a camada JavaScript, que abriga a maior parte da lógica de negócios. É nessa camada que controlamos a maioria das funcionalidades do SDK, incluindo:
- Customização da interface do usuário: Alterar cores, habilitar recursos como preenchimento automático de OTP e muito mais.
- Lógica de pagamento: Lidar com diferentes métodos de pagamento, trocas de aplicativos e callbacks.
A camada JavaScript é projetada para ser flexível e modular. Nós a dividimos em microsserviços, cada um lidando com uma funcionalidade específica. Por exemplo:
- HyperCheckout: Lida com a interface do usuário da página de pagamento.
- EC (Express Checkout): Gerencia as chamadas de backend para processamento de pagamento.
- Plugin UPI: Lida com as trocas de aplicativos UPI e callbacks.
- Godel: Lê e envia automaticamente os OTPs para pagamentos mais rápidos.
Esses microsserviços são orquestrados pelo HyperOS, que atua como o gerenciador central, garantindo que todos os componentes operem juntos sem fricção. Por exemplo, quando um usuário escolhe uma transação com o Google Pay, o HyperOS garante que o Plugin UPI leve o usuário ao aplicativo UPI de sua escolha, registre o final dessa transação e o traga de volta à página de conclusão do pagamento. Já para uma transação com cartão, ele aciona o microsserviço chamado Godel, que opera como um mini navegador da web para trazer uma experiência de transação nativa.
Essa arquitetura ajuda a Juspay a enviar alterações OTA (over-the-air) e garante que o comerciante não precise fazer novas versões de aplicativos para cada pequena mudança na experiência de pagamento. Por exemplo, se os métodos de pagamento forem reordenados pelo comerciante, isso é armazenado como uma alteração de configuração em um dos microsserviços. Quando o usuário abre o aplicativo, as últimas alterações são baixadas pelo SDK e exibidas ao usuário.
Para alcançar a compatibilidade entre plataformas, mantendo o SDK leve, usamos o Presto — o framework de desenvolvimento de aplicativos interno da Juspay. Ao contrário das soluções tradicionais multiplataforma como React Native ou Flutter, o Presto é otimizado para aplicativos com desempenho crítico, como pagamentos. Com o Presto, tornamos nosso SDK verdadeiramente leve. Até 5-10 vezes menor em comparação com React Native ou Flutter. Ele nos permite escrever uma vez e implantar perfeitamente em Android, iOS e Web, reduzindo a necessidade de manter diversas bases de código.
O Desafio
Isso também leva a um desafio. Se o SDK tiver que baixar todas as últimas alterações cada vez que o usuário abre o aplicativo, isso é um problema. Simplificando, os usuários podem desistir porque a página de pagamento não carregou a tempo. A próxima seção discute como continuamos a enfrentar esses desafios.
Ultrapassando os limites de Performance e Adoção
Iteração 1 - Iniciar + Processar
Queremos que nosso SDK funcione bem em todas as condições. Especialmente durante a fase inicial de download e carregamento. Quando um usuário abre um aplicativo pela primeira vez, o SDK precisa baixar os arquivos necessários, que podem ter até alguns MB de tamanho. Esse tempo de download pode levar à desistência do usuário, especialmente se a conexão com a internet for lenta.
Para resolver isso, implementamos um processo de duas etapas:
- Iniciar: Inicializar o SDK e começar a baixar os arquivos necessários. Isso geralmente acontece no pano de fundo quando o usuário abre o aplicativo.
- Processar: Carregar o SDK e iniciar o processamento do pagamento. Isso acontece quando o usuário clica em "Pagar agora" ou CTAs equivalentes.
No entanto, percebemos que esperar que todo o download fosse concluído antes de carregar o SDK não era o ideal. Em vez disso, adotamos uma abordagem paralela de download e carregamento. O SDK começa a carregar imediatamente, mesmo enquanto o download continua no pano de fundo. Isso garante que os usuários possam começar a usar o aplicativo sem esperar que o download completo seja concluído. Com essa abordagem, percebemos uma redução de 50-60% na latência da abertura da página de pagamento.
Iteração 2 - Otimizando Downloads com Manifestos
Para otimizar ainda mais o processo de download, introduzimos um sistema de manifestos. O SDK mantém o controle dos arquivos que baixou e seus hashes. Antes de baixar um arquivo, ele verifica o hash com o armazenado na nuvem. Se os hashes corresponderem, o SDK ignora o download, economizando tempo e largura de banda.
Essa abordagem não apenas melhora o desempenho, mas também reduz os custos, minimizando downloads desnecessários. Com os Manifestos, alcançamos notáveis 0 downloads duplicados.
Iteração 3 - SDK Dinâmico
Com o SDK Dinâmico, cada vez que um comerciante reconstrói seu aplicativo, as versões mais recentes dos microsserviços são agrupadas no aplicativo. Isso garante que o aplicativo sempre tenha os recursos mais atualizados, sem exigir atualizações em tempo de execução. Isso garante que as últimas alterações estejam sempre disponíveis, sem a necessidade de downloads em tempo de execução. Mesmo quando as alterações não são carregadas a tempo, os comerciantes sempre têm uma versão de fallback que carrega, sem esperar por downloads. Ao agrupar os ativos mais recentes de um comerciante com a camada Nativa, na essência, temos 1 SDK que atua como 'n' SDKs Únicos para cada comerciante. Com as duas primeiras iterações, o equilíbrio se inclina para a adoção das últimas alterações, pois há um download das configurações mais recentes sempre que há alterações. Com esta iteração, o equilíbrio é mais voltado para o desempenho. Como a versão mais recente dos Microsserviços é agrupada com o SDK, não há necessidade de novos downloads todas as vezes.
Produção como Playground
Embora várias iterações do SDK tenham ultrapassado os limites de Desempenho e Adoção, implementamos paralelamente sistemas que podem permitir que os comerciantes testem, com segurança, as alterações antes de liberá-las para suas bases de usuários mais amplas. Introduzimos o aplicativo CUG (Controlled User Group). Este aplicativo permite que os comerciantes testem as alterações em um ambiente de produção sem liberá-las para todos os usuários. Depois que as alterações são validadas, elas podem ser implementadas para a base de usuários mais ampla.
Além disso, todos os nossos lançamentos são feitos por meio de um mecanismo de A/B, que escalona as alterações para uma porcentagem selecionada de usuários, monitora métricas de sucesso, como taxas de sucesso e latência, antes de implementar para todos os usuários. Quando são detectados problemas, o sistema retorna às últimas versões estáveis.
Perspectivas para o futuro
Estas são algumas ideias atualmente em brainstorming, para melhorar ainda mais o Desempenho e a Adoção simultaneamente.
Dividindo os Microsserviços para Adoção Mais Rápida
Embora nossa arquitetura atual funcione bem, estamos constantemente procurando maneiras de melhorar. Uma área em que estamos nos concentrando é dividir os Microsserviços em arquivos menores, baseados em recursos. Atualmente, os Microsserviços são pacotes únicos e monolíticos, o que significa que os usuários precisam baixar o pacote inteiro, mesmo que haja uma alteração em uma pequena parte dele.
Ao dividir os Microsserviços em arquivos menores, podemos reduzir o tamanho do download inicial. Por exemplo, se apenas a tela de pagamento com cartão tiver mudado, podemos liberar apenas essa parte do microsserviço HyperCheckout, em vez do pacote inteiro. Essa abordagem melhorará significativamente as taxas de adoção, especialmente para usuários com conexões de internet mais lentas.
Timeouts
Outra melhoria em que estamos trabalhando é a introdução de timeouts para downloads. Nossa implementação atual do SDK Dinâmico carrega as versões agrupadas mais recentes antes de baixar as alterações. Estamos experimentando carregar as alterações com um limite de tempo antes de renderizar a página de pagamento, para impulsionar ainda mais os limites da Adoção.
Conclusão: Uma Experiência de Pagamento Perfeita
Na Juspay, nosso objetivo é tornar os pagamentos o mais fluído possível para comerciantes e usuários finais. Alinhada com nossa aposta inicial em dispositivos de borda, a arquitetura do nosso SDK, com suas camadas nativa e JavaScript, microsserviços e sistema de orquestração, é projetada para atingir esse objetivo. Ao longo dos anos, acompanhamos as inovações nesses dispositivos e no ecossistema de pagamentos mais amplo, otimizando continuamente o desempenho, reduzindo os tamanhos de download e dando aos comerciantes controle sobre as atualizações. Continuaremos a encontrar soluções criativas para melhorar as experiências de pagamento para clientes em todo o mundo.
