OnwardTrust
Fonctionnement

Un paiement, cinq états, et un humain à deux d’entre eux

La version 1 est délibérément réduite et délibérément manuelle. Tout ce qui suit décrit ce qui se passe réellement, y compris les parties qu’aucune machine ne fait encore.

Le parcours de l’argent

Où se trouve l’argent, à chaque instant

En attente du virement
La réservation existe et une référence unique a été émise. Rien n’a bougé. L’agence voit la réservation mais ne dispose d’aucun fonds, et le voyageur peut encore renoncer sans frais.
Crédit reçu
De l’argent est arrivé sur un compte OnwardTrust. Il n’est pas encore rattaché à une réservation — un crédit et un paiement rapproché sont deux choses différentes, et c’est en les confondant que les systèmes de séquestre perdent de l’argent.
Sous séquestre
Rapproché de la réservation par un membre du personnel. L’agence est informée que les fonds sont arrivés et peut émettre en toute confiance. Aucune des deux parties ne peut déplacer l’argent.
Libéré
Justificatif d’émission vérifié, délai de contestation clos, seconde validation obtenue lorsqu’elle est requise. Les fonds partent vers l’agence, déduction faite de la commission.
Restitué
Pas de billet valide, un délai de réservation expiré, ou une contestation retenue. Le voyageur est remboursé sur le compte d’où l’argent provenait. C’est l’issue par défaut dès que quelque chose reste en suspens.

Pourquoi la référence est obligatoire

Un crédit bancaire arrive avec un montant, un émetteur et une ligne de texte libre. Cette ligne est la seule chose qui le relie à une réservation : elle est donc imposée et non simplement encouragée, et son format la rend visiblement distincte de toute autre référence de paiement que traitent nos comptables.

Un crédit qui arrive sans référence n’est pas rejeté — il part dans une file d’attente et une personne remonte à partir du montant et de l’émetteur.

Deux files d’attente humaines

Rapprocher les crédits des réservations, et valider les libérations. Il n’y a pas d’API bancaire en version 1 : ces deux files constituent donc la véritable limite de capacité du produit. Les libérations au-delà d’un seuil exigent un second validateur, et chaque validation est inscrite dans un journal d’audit avec le nom de la personne qui a cliqué.

Quand cela tourne mal

Les cas qui déterminent si l’on fera confiance à tout cela

Un produit de confiance se juge entièrement à ses scénarios défavorables. Ceux-ci sont tranchés à l’avance, pour que personne n’improvise avec l’argent d’autrui.

L’agence n’émet jamais de billet

Le délai de contestation se clôt et le voyageur est intégralement remboursé. L’agence n’a pas à donner son accord, et rien dans le remboursement ne dépend de sa coopération — cette indépendance est toute la raison d’être du dispositif.

Le billet existe mais il est erroné

Mauvais passager, mauvais itinéraire, mauvaise date. Traité comme une absence de billet valide : la vérification du justificatif d’émission porte sur la réservation telle qu’elle a été vendue, et non sur la seule existence d’un numéro de billet.

Le voyageur envoie le mauvais montant

Un paiement insuffisant est signalé plutôt que rejeté automatiquement. Les petits écarts correspondent le plus souvent à des frais d’intermédiaire, et un système qui les renvoie crée deux problèmes au lieu d’en résoudre un. C’est une personne qui décide.

Le voyageur change d’avis

Avant la libération, l’argent reste le sien à tous égards pratiques, et les conditions d’annulation de l’agence s’appliquent à la réservation, non aux fonds. Le séquestre ne crée pas de droit d’annulation, mais il évite d’avoir à réclamer à une agence un remboursement qu’elle a déjà dépensé.

L’argent arrive après l’expiration du délai de réservation

La place peut avoir disparu alors même que le paiement est parfaitement valable. Le crédit est rapproché, la réservation est marquée expirée, et l’argent est restitué plutôt que détenu au titre d’une réservation qui n’existe plus.

Quelqu’un le conteste plus tard

Chaque changement d’état est journalisé avec un horodatage et un acteur, et la page de suivi du voyageur reste accessible pendant 24 mois. Les deux parties consultent le même enregistrement.

Intégration

Ce qu’une agence développe réellement

Une redirection à l’aller, deux webhooks au retour. Nos propres marques de voyage sont le marchand numéro un et utilisent la même API publique : il n’existe donc aucun chemin privé qui fonctionne mieux que le vôtre.

1 · Créer le paiement

Appel côté serveur avec la réservation, le montant, la devise et l’adresse e-mail de votre client. Vous recevez en retour une référence de paiement et une URL de portail.

2 · Envoyer le voyageur

Redirigez vers l’URL du portail au lieu d’afficher vos propres coordonnées bancaires. Tout ce dont le voyageur a besoin — bénéficiaire, IBAN, référence, date limite — s’y trouve.

3 · Écouter deux événements

payment.held vous indique que l’argent est arrivé et que vous pouvez émettre sans risque. payment.released vous indique qu’il a été versé. Un événement payment.returned clôt le scénario défavorable.

Le contrat de l’API marchand s’écrit en même temps que les premières intégrations pilotes plutôt que d’être publié à l’avance, afin que les agences du pilote le façonnent. Demandez-nous la version de travail actuelle.

La suite

Voyez les choses du côté du voyageur

Les quatre écrans que traverse un client, et la page sur laquelle il arrive lorsqu’il cherche notre nom après qu’on lui a demandé de nous virer de l’argent.