Réponse au PDF frontend — 2026-10-30

Bonjour,

Nous avons repris votre PDF du 27 octobre contre l'API staging redéployée et son OpenAPI public. Voici la réponse opérationnelle pour le frontend.

Points désormais couverts

  • Total avant commande : utiliser POST /food/v1/restaurants/{restaurant_id}/quote. Le serveur renvoie le sous-total, la livraison et le total en XOF.
  • Commande non répondue : respond_by est fourni à la création. Le délai par défaut est de cinq minutes. À expiration, Food annule avec restaurant_unresponsive et annule l'intention DiddiPay non payée avec order_expired.
  • Paiement online : customer_email est facultatif. Food utilise le téléphone du payeur authentifié pour produire la valeur technique nécessaire à DiddiPay. Pas de paiement confirmé signifie pas d'acceptation ni de préparation.
  • Suivi livraison : utiliser GET /food/v1/orders/{order_id}/delivery/tracking. DiddiSend reste propriétaire du coursier, de la position, de l'ETA réelle, de la preuve de remise et de la décision après échec.
  • Remboursements : le client crée et relit sa demande avec les routes refund-requests. Support/Backoffice décide et DiddiPay exécute, y compris pour une commande cash. Il n'existe pas de remboursement cash manuel séparé.
  • Restaurant Pro : respond_by, PAYMENT_REQUIRED_BEFORE_PREPARATION, les pièces R7, la soumission, les motifs de refus, les images Cuisine et la lecture d'une note existante sont exposés.
  • Retraits : appeler GET .../wallet/withdrawal-quote, conserver le quote_id, puis l'envoyer dans POST .../wallet/withdrawals avec Idempotency-Key. Le devis confirmé verrouille le montant, les frais et le net pendant sa validité.
  • Catalogue : pagination, recherche légère, filtres de statut/catégorie, recherche GPS et total sont disponibles. Le rayon maximal est de 10 km. La disponibilité des plats est manuelle ; until_end_of_day est refusé.

Contrats à respecter dans l'application

  1. Afficher les montants entiers en XOF et les heures en Africa/Abidjan.
  2. Lire error.code, error.message et error.request_id pour les erreurs.
  3. Ne jamais appeler DiddiPay, DiddiSend ou DiddiFiles directement depuis le frontend.
  4. Ne pas afficher le pickup, la substitution ou la recharge wallet lorsque leurs portes MVP sont désactivées.
  5. Pour un retrait, ne jamais recalculer les frais : réutiliser le quote_id.

Points encore dépendants d'une autre équipe

  • DiddiSend doit publier l'événement d'arrivée du coursier au point de collecte ; Food ne déduit pas cet état depuis la position.
  • DiddiPay doit confirmer la recette staging de l'annulation /payment-intents/{id}/cancel.
  • Les image_url deviennent résolus seulement lorsque les identifiants et le secret S2S DiddiFiles sont configurés dans l'environnement.

Le contrat de référence est docs/api/openapi.json. En staging, /health, /health/ready, /docs, /redoc et /openapi.json répondent actuellement avec succès.