Demandes de paiement
Le payé émet la demande ; le payeur choisit d’y répondre. L’émission d’une demande ne transfère pas de fonds.
Émettre comme payé
Sous /api/v1/{participantCode}, POST /issued-payment-requests crée la demande. La recherche d’alias du payeur précède son émission et son EndToEndId est conservé. Les deux clients doivent avoir un alias. Consultez ensuite GET /issued-payment-requests ou GET /issued-payment-requests/{id}.
Le corps, les informations de remise et les options doivent correspondre au parcours choisi. Reportez-vous au schéma de la référence et aux scénarios Postman du cœur ; ne reprenez pas les noms français du contrat public Business pour construire ce corps.
Traiter comme payeur
| Action | Route sous /api/v1/{participantCode} |
|---|---|
| Lister les demandes reçues | GET /received-payment-requests |
| Lire une demande | GET /received-payment-requests/{id} |
| Accepter | PUT /received-payment-requests/{id}/acceptance |
| Refuser | PUT /received-payment-requests/{id}/rejection |
Présentez uniquement les demandes dont les contrôles le permettent ; les filtres status=RECEIVED&controlResult=PASSED servent ce parcours. Le canal reçoit aussi les événements de demande de paiement sur la famille Kafka dédiée au participant.
Payer immédiatement déclenche un transfert du cœur. Suivez son résultat financier, distinct de l’acceptation de la demande. Payer plus tard ne se propose que pour les parcours autorisés et une échéance admissible ; l’acceptation programme alors le paiement sans émettre un message d’acceptation à PI.
Une demande expirée, déjà traitée ou refusée ne doit pas donner lieu à un second paiement. Consultez son état après une réponse ambiguë avant toute nouvelle action.