Oui, avec le même endpoint de création et un seul indicateur. purchase_info.as_pending: true crée la réservation à l’état pending : elle gèle le créneau et le prix, le bloc client est facultatif et elle reste toujours impayée.

Statut et paiement sont deux axes indépendants. as_pending décide pending ou confirmée ; paid décide seulement si elle est déjà payée. Une réservation confirmée mais pas encore payée est un état valide : omettez as_pending et envoyez paid: false.

Depuis une réservation en attente :

PUT .../booking/{uuid}/confirm la transforme en réservation confirmée. Le client est ici obligatoire. Renvoie 410 Gone si le blocage a déjà expiré.
PUT .../booking/{uuid}/payment-in-progress raccourcit la fenêtre d’expiration pendant que vous encaissez.
PUT .../booking/{uuid}/cancel la libère sans pénalité.

Une réservation en attente ne vit pas indéfiniment : elle est libérée automatiquement au bout d’une fenêtre que le centre configure dans son back-office, et aucune API ne permet de la lire ni de la modifier. La lecture de la réservation renvoie un objet expiry avec expires_at et remaining_seconds tant qu’elle est pending, et null ensuite.

Public APIDocumentation