Ce fichier décrit l'intégration paiement et payout entre DiddiFood et DiddiPay. Il s'adresse aux équipes Food, DiddiPay, frontend et QA.
DiddiPay possède le paiement, les mouvements d'argent et les payouts. Food garde la commande, le montant calculé et l'état local de réconciliation.
Paiement online
Food crée une intention de paiement. customer_email est optionnel côté client; Food transmet toujours à DiddiPay une valeur email valide, dérivée du téléphone du payeur authentifié si nécessaire.
Remboursement
Après validation Support/Backoffice, Food appelle DiddiPay avec une Idempotency-Key. Pour une commande online, l'appel référence l'intention de paiement. Pour une commande cash_on_delivery, l'appel utilise le contrat destination-aware POST /refunds avec business_reference, beneficiary_reference, recipient_user_id, le montant XOF et le motif. Food ne règle jamais un remboursement cash manuellement et ne choisit pas le portefeuille final.
Le endpoint destination-aware doit être disponible dans DiddiPay avant l'activation staging de cette branche; sinon Food renvoie DIDDIPAY_ERROR et laisse la demande en échec pour traitement contrôlé.
Retrait restaurant
Food demande un payout a DiddiPay apres reservation du solde restaurant.
Variables principales:
DIDDIPAY_BASE_URL=https://pay-api-staging.diddifree.com/payfund/v1
DIDDIPAY_CLIENT_ID=diddifood
DIDDIPAY_SERVICE_KEY=...
DIDDIPAY_SERVICE_CLIENT_SECRET=...
DIDDIPAY_CALLBACK_SECRET=...
DIDDIPAY_PAYOUT_PATH=/payouts
DIDDIPAY_SERVICE_KEY et DIDDIPAY_CALLBACK_SECRET doivent etre distincts.
À l'expiration d'une commande non répondue, DiddiFood annule une intention
encore pending ou requires_action avec POST
/payment-intents/{id}/cancel, le motif order_expired et la clé
food-order:<order_id>:expire-payment. Une intention succeeded n'est jamais
annulée par ce chemin : elle passe par la demande de remboursement approuvée.
À confirmer par DiddiPay
- frais reels de retrait,
- contrat final
POST /payouts, - statut de reconciliation payout,
- format exact des erreurs prestataire.