Este artigo é o quarto de uma série sobre como a equipe de engenharia móvel da Uber desenvolveu a versão mais recente do nosso aplicativo do motorista, codinome Carbon, um componente essencial de nosso negócio de compartilhamento de viagens.

Entre outros novos recursos, o aplicativo permite que nossa população de mais de três milhões de motoristas parceiros encontre tarifas, obtenha rotas e acompanhe seus ganhos.

Começamos a projetar o novo aplicativo em conjunto com o feedback de nossos motoristas parceiros em 2017 e começamos a implementá-lo para produção em setembro de 2018.

Como uma empresa global, a Uber se esforça para tornar seus serviços acessíveis em todos os lugares onde opera. Esse esforço envolve entender os costumes regionais e adaptar nossa tecnologia a eles.

O que é fundamental nessa busca é permitir que os clientes paguem da maneira que faz mais sentido para eles, seja crédito, débito ou tipos de pagamento específicos da região, como dinheiro.

Em muitos mercados onde o serviço de compartilhamento de viagens da Uber e a Uber Eats estão disponíveis, os cartões de crédito e débito não são comuns nem o método de pagamento escolhido.

No entanto, até 2016, esses métodos digitais eram o principal tipo de pagamento suportado, tornando difícil para os usuários que preferiam e/ou podiam pagar apenas em dinheiro alavancar nossos serviços.

Abordamos essa limitação primeiramente aceitando pagamentos em dinheiro para passeios de Uber em Mumbai, onde uma pequena porcentagem da população da cidade tem cartões de crédito.

Como os clientes receberam bem essa nova opção no tipo de pagamento, expandimos os pagamentos em dinheiro para corridas em toda a Índia, América Latina e África.

No entanto, foi só em setembro de 2017 que começamos a aceitar pagamentos em dinheiro para os pedidos de entrega da Uber Eats, uma oferta originada novamente em Mumbai.

Esse atraso de dois anos foi causado pela complexidade dos pagamentos do mercado de três lados da Uber Eats, composto por restaurantes parceiros, entregadores parceiros e comedores/consumidores.

A superação desse desafio envolveu uma mistura de mudanças operacionais e novas tecnologias. Em particular, nosso novo aplicativo do motorista (codinome Carbon) nos forneceu novos recursos que ajudaram a suportar o dimensionamento de uma economia baseada em dinheiro. Com essas inovações, podemos levar a Uber Eats para mais clientes em todo o mundo.

O desafio de coletar dinheiro

Nas cidades onde oferecemos suporte a pagamentos em dinheiro para o nosso serviço de compartilhamento de viagens, os motoristas parceiros retêm o dinheiro pago a eles em dinheiro e pagam as taxas da Uber por essas viagens automaticamente a partir dos lucros de viagens pagas digitalmente.

Nessas circunstâncias, nosso sistema inteligente de despacho garante que os motoristas parceiros recebam viagens suficientes pagas com um tipo de pagamento digital para cobrir as taxas devidas à Uber de viagens em dinheiro anteriores.

Os motoristas se beneficiam de um pagamento imediato, enquanto a Uber permite que os passageiros paguem com dinheiro físico, uma característica importante em regiões onde algumas pessoas não têm acesso a cartões de crédito.

Com o mercado de três lados da Uber Eats, a maioria do dinheiro recebido por um entregador parceiro de um consumidor é devido ao restaurante parceiro. Além disso, em mercados com baixa utilização de cartão de crédito ou débito, não é possível despachar entregas digitalmente pagas suficientes para compensar o caixa em circulação.

Em vez de pedir aos nossos entregadores parceiros que voltassem para os restaurantes de onde vieram para deixar o dinheiro pago por um pedido, precisávamos de um meio sustentável de transferir pagamentos em dinheiro entre o consumidor e o restaurante parceiro.

Primeiro, tentamos usar serviços de cobrança em dinheiro de terceiros que alavancam locais participantes, como lojas de conveniência, bem como depósitos e transferências bancárias tradicionais.

O problema que encontramos com essa abordagem foi que esses serviços não estavam disponíveis em todas as cidades da Uber Eats, limitando onde podíamos suportar pagamentos em dinheiro e exigindo que nossos entregadores parceiros fizessem paradas que não faziam parte da experiência tradicional de viagem de entrega.

Nosso mecanismo ideal de coleta de caixa precisava funcionar em todos os mercados atuais e futuros da Uber Eats, além de ser conveniente para entregadores parceiros. Além disso, como muitos mercados habilitados para pagamento em dinheiro possuem conectividade de rede não confiável, a operação de troca de caixa precisava ser capaz de funcionar totalmente off-line.

Nossa nova abordagem

A proposta do produto era inovadora: alavancar nossos restaurantes parceiros como uma rede distribuída de locais de entrega de dinheiro.

Os entregadores parceiros com um saldo de caixa pendente de viagens anteriores seriam despachados para os restaurantes participantes e pagariam pelo pedido em dinheiro, independentemente do tipo de pagamento do consumidor.

Para evitar fricção desnecessária durante a coleta, o valor do pagamento seria igual ao valor do pedido, pois receber um valor diferente poderia gerar confusão para o caixa de um restaurante.

Os restaurantes manteriam todos os ganhos em dinheiro e se beneficiariam do pagamento imediato. A Uber cobriria suas taxas de reserva de entrega deduzindo-as de pedidos digitais subsequentes.

Esse mecanismo funciona bem porque é escalável nos mercados atuais e futuros da Uber Eats e tornam os pagamentos em dinheiro uma parte regular da experiência de entrega, integrando-os a cada viagem. Nosso próximo desafio foi garantir que a cobrança em atraso de restaurante funcionasse offline.

Felizmente, criamos suporte off-line em nosso novo aplicativo do motorista para cobrir vários casos de uso, como quando um motorista termina uma viagem em uma área com cobertura de rede limitada. Esse recurso combinava muito bem com nossos requisitos para pagamentos em dinheiro.

Aproveitando o modo otimista

Em muitos mercados emergentes, onde a Uber opera, conectividade de rede confiável não é uma garantia. Nosso aplicativo do motorista anterior exigia conectividade de rede durante toda a viagem, o que poderia resultar em experiências incrivelmente frustrantes para nossos motoristas e entregadores parceiros.

Por exemplo, um motorista pode ter que dirigir para uma área com conectividade depois de deixar um cliente para encerrar a viagem no aplicativo. Esse problema pode ser pior para os entregadores parceiros, onde os embarques e entregas subterrâneas e em prédios interferem ainda mais nas conexões de rede.

Entre os muitos recursos novos do nosso aplicativo de motorista reprojetado está o Optimistic Mode, que permite que os recursos funcionem e progridam sem a necessidade de uma conexão de rede.

Quando ativado, o estado do aplicativo será atualizado imediatamente e permanecerá responsivo, independentemente de as solicitações de rede serem ou não bem-sucedidas.

As solicitações com falha serão observadas, armazenadas em cache e novamente tentadas quando a conectividade for restaurada. Independentemente da latência real da rede, o aplicativo responde rapidamente, permitindo que o usuário interaja com ele normalmente.

Com o Modo Otimista, as viagens podem começar e terminar imediatamente em áreas com pouca ou nenhuma conectividade. Para a Uber Eats, os entregadores parceiros podem progredir por todo o fluxo de coleta de dinheiro do restaurante sem uma conexão de rede.

O recurso de cobrança em atraso do restaurante

Permitir que os restaurantes coletem ininterruptamente os atrasos dos entregadores parceiros, exigiu atualizações para nossos novos aplicativos de motorista para Android e iOS e nosso aplicativo de Painel de Restaurantes, escrito com o React Native, bem como a nova funcionalidade de back-end.

Nós construímos um novo microsserviço para suportar entregas de caixa de restaurantes e seus clientes com as seguintes responsabilidades:

• Determinar a elegibilidade da viagem para pagamentos em dinheiro no restaurante.
• Calcular as quantias sugeridas de dinheiro para pagar.
• Manter o estado das viagens de pagamento em dinheiro do restaurante em curso com uma máquina de estado.
• Formatar e fornecer dados de exibição aos clientes móveis, bem como ao nosso aplicativo de restaurante.

Com este paradigma, uma entrega de caixa tem vários estados possíveis, visualizados na Figura 1, abaixo:

No despacho, os entregadores parceiros optam por concluir uma entrega de caixa por padrão, já que ativamente optar posteriormente pode exigir uma conexão de rede. Neste ponto inicial da viagem, mostrado na Figura 2, podemos assumir com segurança que um entregador parceiro tem conectividade, caso contrário, eles não receberiam o despacho.

Enviamos todas as informações necessárias para concluir o fluxo, para que as etapas subsequentes não requeiram uma conexão de rede e informem ao restaurante a possível transação em dinheiro, mostrada na Figura 3.

Um entregador parceiro pode optar por não efetuar um pagamento em dinheiro e continuar o fluxo de entrega, pois o Modo Otimista gravará solicitações de rede com falha no disco. Ao recuperar a conectividade, o back-end será notificado da decisão de pular temporariamente o pagamento.

O serviço suporta os entregadores parceiros definindo os valores que eles podem pagar, o que é útil se um entregador parceiro não tiver todo o dinheiro solicitado em mãos ou quiser troco para entregas futuras.

No entanto, não ativamos esse recurso, pois é necessário pensar mais em torno da experiência do restaurante em aceitar pagamentos em dinheiro que diferem do total do pedido.

Na prática atual, se um entregador parceiro optar por concluir o pagamento em dinheiro, ele entrará no estado de troca de pagamento com o valor do dinheiro definido automaticamente para o valor do pedido.

Então, como podemos realizar a troca de pagamento em dinheiro offline? Exigindo que tanto o restaurante quanto o entregador parceiro reconheçam que um pagamento em dinheiro ocorreu tranquiliza todas as partes e é o mais resistente a possíveis fraudes.

Como não podemos confiar em solicitações de rede para fornecer notificações instantâneas a ambas as partes após a confirmação, utilizamos a troca de um código de quatro dígitos.

Fornecemos ao aplicativo do motorista e ao aplicativo do restaurante todas as informações necessárias para concluir o fluxo no envio.

O restaurante recebe um código gerado aleatoriamente, mostrado na Figura 4, abaixo, e o entregador parceiro é instruído a solicitá-lo no ponto de troca.

Por outro lado, enviamos ao cliente móvel o SHA256 salted hash desse código, que é comparado com o código hash do cliente inserido posteriormente pelo entregador parceiro quando ele é recebido do restaurante.

Após a entrada de código bem-sucedida, o entregador parceiro pode continuar o fluxo e começar a próxima etapa da viagem. A verificação de igualdade dos valores com hash ocorre totalmente offline. Para evitar fraudes, a limitação de taxas e o número máximo de tentativas são impostos.

Além disso, a opção de pagar em dinheiro expirará após uma duração razoável se não for concluída. Se uma inconsistência de transação for descoberta, a Uber investigará mais e possivelmente proibirá quaisquer agentes mal-intencionados da plataforma.

Após a entrada do código com sucesso, mostrada na Figura 5, acima, uma tela de confirmação pré-preenchida é mostrada para o entregador parceiro e o restaurante. Se ocorrer uma falha de rede novamente, o Modo Otimista gravará a solicitação com falha no disco e tentará novamente quando a conectividade for restaurada.

O entregador parceiro será creditado pelo pagamento e o saldo do restaurante parceiro será ajustado em relação aos ganhos digitais futuros, completando assim o pagamento em dinheiro.

Avançando com pagamentos em dinheiro

Embora originalmente destinado ao fluxo de viagem principal do Carbon, o Modo Otimista tornou possível um conjunto totalmente novo de recursos. As equipes de Engenharia e Design da Uber não estão mais restritas pelo requisito de conectividade de rede ao criar novos recursos.

Como a entrega de dinheiro requer confiança significativa de várias partes, confiar apenas no restaurante para verificar se as transações de cobrança em atraso não funcionaria.

No entanto, exigir que o entregador parceiro tenha conectividade de rede pode impedir que a viagem progrida, deixando o parceiro preso em um fluxo de verificação.

O Modo Otimista fornece a solução perfeita, permitindo que a operação de transferência ocorra totalmente off-line, com o back-end sendo posteriormente informado da transação quando uma conexão de rede é restabelecida.

Reconhecendo o valor do suporte off-line, outras equipes que contribuem para o Carbon estão aproveitando o Modo Otimista, enquanto a equipe da Plataforma de Rede Móvel da Uber expande a funcionalidade do framework.

Esses esforços em Carbon estão transformando o aplicativo dependente de rede da Uber para um que seja responsivo em todos os mercados em que a Uber opera, independentemente da conectividade.

Índice para a série de artigos do aplicativo do motorista

• 1 – Por que decidimos reescrever o aplicativo do motorista da Uber
• 2 – Arquitetando o novo aplicativo de motorista da Uber em RIBs
• 3 – Como o novo aplicativo de motorista da Uber supera o atraso da rede
• 4 – Dimensionamento de pagamentos em dinheiro na Uber Eats
• 5 – Como entregar uma reescrita de aplicativo sem arriscar seu negócio inteiro

Interessado em desenvolver aplicativos móveis usados ​​por milhões de pessoas todos os dias? Considere se juntar à nossa equipe como desenvolvedor Android ou iOS!

***

Este artigo é do Uber Engineering. Ele foi escrito por Steven Austin. A tradução foi feita pela Redação iMasters com autorização. Você pode conferir o original em: https://eng.uber.com/driver-app-cash-payments/