OnwardTrust
Como funciona

Um pagamento, cinco estados e uma pessoa em dois deles

A versão 1 é deliberadamente pequena e deliberadamente manual. Tudo o que se segue descreve o que acontece na realidade, incluindo as partes que uma máquina ainda não faz.

O percurso do dinheiro

Onde está o dinheiro, a cada momento

A aguardar transferência
A reserva existe e foi emitida uma referência única. Nada se moveu. A agência vê a reserva mas não tem fundos, e o viajante pode ainda desistir sem qualquer custo.
Crédito recebido
O dinheiro chegou a uma conta da OnwardTrust. Ainda não está ligado a nenhuma reserva — um crédito e um pagamento associado são coisas diferentes, e confundi-las é a forma como os sistemas de depósito em garantia perdem dinheiro.
Retido
Associado à reserva por um membro da equipa. A agência é notificada de que os fundos estão aqui e pode emitir com confiança. Nenhuma das partes pode mover o dinheiro.
Libertado
Comprovativo de emissão verificado, prazo de contestação encerrado, segunda aprovação obtida sempre que exigida. Os fundos seguem para a agência, deduzida a comissão.
Devolvido
Sem bilhete válido, com a reserva expirada ou com uma contestação julgada procedente. O viajante é reembolsado na conta de onde o dinheiro veio. Este é o desfecho por defeito sempre que algo fica por resolver.

Porque é que a referência é obrigatória

Um crédito bancário chega com um montante, um remetente e uma linha de texto livre. Essa linha é a única coisa que o liga a uma reserva, por isso é imposta e não apenas recomendada, e tem um formato visivelmente distinto de qualquer outra referência de pagamento que os nossos contabilistas tratem.

Um crédito que chegue sem ela não é rejeitado — vai para uma fila e uma pessoa reconstitui a origem a partir do montante e do remetente.

Duas filas humanas

Associar créditos a reservas e aprovar libertações. Não existe API bancária na versão 1, por isso estas duas filas são o verdadeiro limite de capacidade do produto. As libertações acima de um determinado valor exigem um segundo aprovador, e cada aprovação é escrita num registo de auditoria com o nome de quem clicou.

Quando corre mal

Os casos que decidem se alguém confia nisto

Um produto de confiança é julgado inteiramente pelos seus cenários desfavoráveis. Estão respondidos de antemão para que ninguém improvise com o dinheiro de outra pessoa.

A agência nunca emite o bilhete

O prazo de contestação encerra e o viajante é reembolsado na totalidade. A agência não tem de concordar e nada no reembolso exige a sua colaboração — essa independência é todo o objetivo deste acordo.

O bilhete existe mas está errado

Passageiro errado, rota errada, data errada. Tratado como ausência de bilhete válido: a verificação do comprovativo de emissão é feita por confronto com a reserva tal como foi vendida, e não apenas com a existência de um número de bilhete.

O viajante envia o montante errado

Um pagamento insuficiente é sinalizado em vez de rejeitado automaticamente. As pequenas diferenças são normalmente comissões de bancos intermediários, e um sistema que as devolve cria dois problemas em vez de resolver um. É uma pessoa que decide.

O viajante muda de ideias

Antes da libertação, o dinheiro continua a ser dele em todos os sentidos práticos, e as condições de cancelamento da agência aplicam-se à reserva e não aos fundos. O depósito em garantia não cria um direito de cancelamento, mas significa que ninguém anda a perseguir uma agência por um reembolso que ela já gastou.

O dinheiro chega depois de a reserva expirar

O lugar pode já não existir mesmo que o pagamento esteja correto. O crédito é associado, a reserva é marcada como expirada e o dinheiro é devolvido em vez de ficar retido por conta de uma reserva que já não existe.

Alguém contesta mais tarde

Cada mudança de estado é registada com data, hora e autor, e a página de estado do viajante permanece disponível durante 24 meses. O registo é o mesmo para ambas as partes.

Integração

O que uma agência constrói na prática

Um redirecionamento para fora, dois webhooks de volta. As nossas próprias marcas de viagens são o comerciante número um e usam a mesma API pública, por isso não existe um caminho privado que funcione melhor do que o seu.

1 · Criar o pagamento

Chamada do lado do servidor com a reserva, o montante, a moeda e o e-mail do seu cliente. Recebe de volta uma referência de pagamento e um URL do portal.

2 · Enviar o viajante

Redirecione para o URL do portal em vez de mostrar os seus próprios dados bancários. Tudo aquilo de que o viajante precisa — beneficiário, IBAN, referência, prazo — está lá.

3 · Escutar dois eventos

payment.held indica-lhe que o dinheiro entrou e que é seguro emitir. payment.released indica-lhe que já foi pago. Um evento payment.returned encerra o cenário desfavorável.

O contrato da API para comerciantes está a ser escrito em conjunto com as primeiras integrações do piloto, em vez de publicado com antecedência, para que sejam as agências do piloto a moldá-lo. Peça-nos o rascunho atual.

A seguir

Veja do lado do viajante

Os quatro ecrãs por que passa um cliente, e a página onde aterra quando procura o nosso nome depois de lhe pedirem para nos transferir dinheiro.