Aller au contenu
Candidater

Journal des modifications

Les évolutions de Cohez.io, de la plus récente à la plus ancienne.

52 versions correspondent à « paiement ».

Versions 31 à 40 sur 52

0.16.3.0 — 2026-06-03

Ajouts

  • Traçabilité des emails de relance : chaque email de relance envoyé pour un dossier d'inscription est désormais enregistré (paiement HelloAsso rejeté, paiement abandonné, ou acompte expirant), avec le destinataire, la raison, la référence de checkout et la date d'envoi.
  • Historique des relances sur la vue dossier : une carte « Relances envoyées » liste les relances du dossier, avec un badge coloré par type (rejeté, abandonné, acompte) et l'horodatage de chaque envoi.

Technique

  • Nouvelle table registration_relance_emails (une ligne par email) et table pivot vers les dossiers concernés (un email groupé peut couvrir plusieurs dossiers).
  • L'enregistrement des traces est centralisé dans un recorder best-effort (RegistrationRelanceEmail::record()), branché sur le goulot d'envoi HelloAsso et sur la relance d'acompte. Une défaillance de la trace n'interrompt jamais l'envoi du mail.

0.16.2.0 — 2026-06-03

Corrections

  • Webhook HelloAsso Refused tardif : un webhook de refus livré en retard pour un checkout périmé (la référence ayant été écrasée lors d'un retry) ne re-marque plus Rejected un paiement déjà retenté sous une nouvelle référence. resolvePayments() filtre désormais sur la référence du checkout courant (filtre gardé : repli sur la résolution par registration_id si le checkoutIntentId est absent du payload). Évite qu'une inscription reste bloquée en Draft alors que le paiement a abouti sur le nouveau checkout. Contrat data.checkoutIntentId confirmé sur un webhook de production.

0.15.0.0 — 2026-06-02

Ajouts

  • Relance paiement HelloAsso : les payeurs dont le paiement HelloAsso est rejeté par la banque ou abandonné depuis plus de 2h reçoivent automatiquement un email de relance avec le récapitulatif de leur inscription et un lien sécurisé pour relancer le paiement (URL signée, valable 7 jours).
  • Route de retry HelloAsso (/register/{token}/helloasso/retry) : crée un nouveau checkout HelloAsso à la volée sans effacer l'inscription existante. Protégée par URL signée temporaire pour prévenir les accès non autorisés.
  • Statuts de paiement HelloAsso dans l'interface admin : les inscriptions affichent désormais "HelloAsso en attente" (badge orange) et "Paiement refusé" (badge rouge) pour distinguer visuellement les checkouts en cours des paiements rejetés par la banque.
  • Détail complet du panier dans l'email de relance : l'email de relance affiche désormais chaque adhérent inscrit avec le détail par rubrique, les réductions appliquées, le montant de l'acompte le cas échéant et sa date d'expiration.
  • Planification nocturne : helloasso:sync-pending-payments s'exécute automatiquement chaque nuit à 06:00 (Europe/Paris) pour rattraper les paiements en attente non notifiés par webhook.
  • Annulation automatique : lorsqu'une inscription passe en statut Abandonné ou Annulé, les paiements HelloAsso Pending/Rejected associés sont automatiquement annulés pour éviter les relances intempestives.

Modifications

  • La commande helloasso:sync-pending-payments envoie maintenant un email de relance lors de la détection d'un paiement rejeté ou d'un checkout abandonné (>2h), avec idempotence garantie par le flag helloasso_relance_sent_at sur les paiements.
  • Le webhook HelloAsso (Refused) envoie immédiatement un email de relance au payeur après avoir marqué le paiement comme rejeté.
  • Les inscriptions en statut terminal (Refusé, Annulé, Abandonné) sont exclues des relances automatiques.
  • La logique d'envoi de l'email de relance est désormais centralisée dans HelloAssoRelanceService pour éviter la duplication entre le webhook et la commande de synchronisation.

Corrections

  • Correction d'un bug de double-email : après un retry, le délai de grâce de 2h pour la relance des abandonnés repart maintenant correctement de la date de modification du paiement (et non de sa création initiale).
  • json_decode sur les notes de paiement corrompues retourne désormais [] au lieu de null, évitant un recalcul incorrect du montant lors d'un retry de dépôt.
  • La route de retry ne supprime plus les inscriptions existantes en cas d'échec de l'API HelloAsso (contrairement au flux initial d'inscription).
  • L'URL de relance (bouton "Finaliser mon paiement") utilisait la racine de l'application au lieu du sous-domaine tenant, provoquant une erreur 404 à la réception de l'email.
  • Ajout du statut Cancelled dans l'enum PaymentStatus (manquant depuis la création, causait une erreur 500 lors de l'annulation d'inscription).

0.14.2.0 — 2026-06-01

Modifications

  • Confirmation des paiements HelloAsso : la logique de confirmation (paiement reçu, transition de statut, envoi d'email) est désormais centralisée dans un service dédié, éliminant trois implémentations divergentes (retour URL, webhook, commande de synchronisation). Les guards d'idempotence sont désormais uniformes sur tous les états terminaux (Received, Rejected, Refunded, Contested).
  • Checkout HelloAsso : les deux blocs de création de paiement dans le formulaire d'inscription (paiement standard et acompte) sont fusionnés en un service unique.

Corrections

  • L'événement RegistrationValidated (déclenchant la création de facture et l'email de confirmation) est maintenant émis après le commit de la transaction de paiement, garantissant que les listeners synchrones opèrent sur des données pleinement persistées.
  • L'idempotence du retour HelloAsso ignorait les états Rejected, Refunded et Contested — désormais alignée avec le webhook.

0.14.1.4 — 2026-06-01

Ajouts

  • Couverture complète des états de paiement HelloAsso : le webhook et la commande helloasso:sync-pending-payments gèrent désormais tous les états HelloAsso — Refused → Rejected, Refunding/Refunded → Remboursé, Contested → Contesté. L'interface affiche les badges correspondants avec les variantes visuelles adaptées.

Corrections

  • Guard d'idempotence webhook étendu : lors d'un retry de webhook Paid, le handler vérifie maintenant tous les états terminaux (Received, Refunded, Contested, Rejected) avant d'écrire — empêchant un webhook retardé d'écraser un remboursement déjà enregistré.
  • Guard d'idempotence sync étendu : helloasso:sync-pending-payments applique le même guard (tous les états terminaux) pour éviter qu'une exécution concurrente avec un webhook ne réécrive un paiement Refunded/Contested avec Received.
  • Filtre méthode de paiement dans resolvePayments() : les paths 1 et 2 de résolution (par registration_ids[] et registration_id) filtraient tous les paiements d'une inscription ; ils filtrent maintenant uniquement ceux de méthode HelloAsso, évitant de marquer des paiements espèces/chèque comme rejetés/remboursés.
  • Compteur --dry-run : le compteur de paiements mis à jour n'était pas incrémenté dans le bon bloc conditionnel pour les checkouts refusés, affichant un compte erroné en mode dry-run.
  • Types TypeScript : Payment.status dans la page inscription inclut désormais 'refunded' et 'contested' ; les badges s'affichent correctement pour ces états.

0.14.1.3 — 2026-05-30

Ajouts

  • Commande helloasso:sync-pending-payments : nouvelle commande artisan pour récupérer les paiements HelloAsso restés en attente après un webhook manquant. Pour chaque tenant avec credentials HelloAsso, interroge l'API pour tous les paiements Pending ayant une référence, et confirme automatiquement ceux qui sont payés (transition Draft → Validated, email de confirmation). Options : --tenant=UUID pour restreindre à un seul tenant, --dry-run pour prévisualiser sans modifier.

Corrections

  • Webhook HelloAsso sans webhook_secret : les tenants sans clé partenaire HelloAsso recevaient 401 Webhook secret not configured sur chaque notification, laissant les paiements en Draft indéfiniment. Le webhook accepte désormais les requêtes provenant des IPs officielles HelloAsso (51.138.206.200 prod, 4.233.135.234 sandbox) quand aucun secret n'est configuré — conformément à la méthode de validation documentée par HelloAsso pour les non-partenaires.
  • Rejet HelloAsso sur lastName invalide : l'API HelloAsso rejetait l'erreur Le champ nom est invalide quand le nom du payeur contenait un seul caractère, des chiffres ou des accents non supportés (ü, ñ…). Les champs firstName/lastName du payeur sont maintenant omis du checkout intent — HelloAsso les collecte directement sur sa page de paiement.

0.14.1.0 — 2026-05-29

Ajouts

  • Configuration HelloAsso per-tenant (sandbox / production) : chaque tenant peut désormais utiliser un environnement HelloAsso distinct. Un super-admin bascule le mode depuis la fiche Filament via le bouton "Environnement HelloAsso" — un modal avec sélection Radio et confirmation obligatoire ("PRODUCTION") protège contre les clics accidentels. Le badge SANDBOX/PRODUCTION est visible en temps réel dans l'infolist. Le token OAuth2 est automatiquement invalidé lors du changement d'environnement.
  • Bandeau "Mode test HelloAsso" dans le wizard d'inscription public : quand un tenant est en mode sandbox, un bandeau amber persistant ("Aucun paiement réel ne sera encaissé") s'affiche sur toutes les étapes du formulaire, empêchant toute confusion entre paiements réels et tests.

0.13.8.0 — 2026-05-27

Corrections

  • Backoffice inscriptions — notes JSON visibles : les métadonnées internes HelloAsso stockées dans le champ notes du paiement (objet JSON {"checkout_type":"deposit","checkout_url":"…"}) s'affichaient en clair dans l'historique des paiements. Ces notes internes (débutant par {) sont désormais masquées dans la vue.

0.13.5.0 — 2026-05-26

Corrections

  • Description par moyen de paiement dans le récapitulatif public : les instructions spécifiques à chaque méthode (ex. : coordonnées bancaires pour un virement) s'affichent désormais sous le libellé dans l'étape récap du wizard d'inscription. Les descriptions sont éditables directement depuis la page Paramètres › Moyens de paiement, pour les méthodes standard et personnalisées.
  • Acompte ignoré pour les méthodes de paiement personnalisées : lors d'une inscription avec acompte, le déclenchement du dépôt était systématiquement ignoré pour les méthodes personnalisées. La règle d'acompte stocke l'UUID de la méthode dans applicable_payment_methods, mais le service comparait la valeur d'enum 'custom' au lieu de l'UUID — corrigé des deux côtés (service et contrôleur).
  • Onglet par défaut sur la fiche membre : l'onglet affiché à l'ouverture d'une fiche membre était « Activités » ; il est maintenant correctement positionné sur « Identité ».
  • Libellé onglet corrigé : l'onglet « Adhérent » est renommé « Adhésion » pour correspondre au contenu affiché.
  • Noms de cours dans la liste des inscriptions : la colonne campagne affiche maintenant les activités rattachées (ex. : « Yoga débutant ») sous le nom de la campagne, facilitant l'identification rapide.

Interne

  • Migration add_description_to_tenant_payment_methods_table : colonne description TEXT NULL sur tenant_payment_methods, réversible.
  • Nouvelle route PATCH /settings/payment-methods/{method} pour la mise à jour de la description (contrôleur, validation, tests).
  • RegistrationController::index() refactorisé avec foreach pour résoudre PHPStan null-safe sur $p->course et eager loading propositions.course ajouté.
  • Tests de régression : service-level pour bug 1f (méthode personnalisée + règle d'acompte), controller-level pour bug 2d (courseNames).

0.13.4.0 — 2026-05-26

Corrections

  • Inscription famille avec email partagé tuteur/enfant : l'inscription d'un mineur dont le tuteur utilise la même adresse email que l'enfant réussit désormais. Auparavant, la déduplication par email seul confondait le tuteur avec l'enfant et provoquait une erreur « déjà inscrit » injustifiée.
  • Page de succès blanche après inscription : la page de confirmation s'affichait vide à cause d'une propriété Vue 3 non assignée (defineProps() non capturé). Le titre, le statut de paiement et les informations d'acompte s'affichent maintenant correctement.

Interne

  • Suppression de deux blocs try/catch(UniqueConstraintViolationException) devenus inaccessibles depuis la suppression de la contrainte unique sur persons.email (février 2026).
  • Test de régression ajouté pour le scénario tuteur/enfant à email partagé, couvrant la création distincte des deux Persons et le flag is_minor.