Ce guide décrit le parcours ordinaire d'une livraison Food confiée à DiddiSend. Il s'adresse aux équipes Food, Send, frontend et QA.

1. Après l'acceptation du restaurant, Food envoie POST /food/v1/restaurants/{restaurant_id}/orders/{order_id}/delivery/request à son adaptateur DiddiSend.
2. Le payload contient la commande, le montant XOF immuable, customer_user_id, une clé d'idempotence et exclusive=true avec le véhicule motorcycle.
3. DiddiSend reste propriétaire de l'affectation, du pickup, du trajet, de la collecte cash et de la remise.
4. Food expose GET /food/v1/orders/{order_id}/delivery/tracking comme surface stable pour le client. Food vérifie l'accès à la commande, lit DiddiSend ou sa projection locale, puis filtre les données publiques. Le worker HTTP est activé par DELIVERY_STATUS_SYNC_ENABLED.
5. L'événement delivery.cash_remitted est consommé par le worker wallet lorsque PAYOUT_CONSUMER_ENABLED=true; avant cette validation, le gain cash reste en attente.

Échec de livraison

DiddiSend peut publier ou retourner delivery.failed avec delivery_id, order_id/order_reference, failure_code, failure_reason, status_at et event_version=1. Food stocke ces champs dans sa projection et les expose au client comme status=failed, failure_code et failure_reason. Food ne choisit ni nouvelle tentative, ni annulation, ni remboursement : cette décision appartient à DiddiSend avec Support/Backoffice.

sequenceDiagram
    participant F as DiddiFood
    participant S as DiddiSend
    participant W as Wallet Food
    F->>S: POST delivery/request + idempotency
    S-->>F: remote_delivery_id
    S-->>F: pickup/delivered et cash_remitted
    F->>W: crédit idempotent après remise cash

DiddiFood ne gère jamais les livreurs ni leur machine d'état. customer_user_id sert à attribuer la note client au bon acheteur, tandis que le compte technique Food reste l'expéditeur S2S.