BCard - Documentation technique

Calcule à la volée le montant d'un abonnement pour l'affichage dynamique du tunnel.

Lit plan_id, billing_cycle et employee_count (converti en entier, 1 par défaut) dans le corps de la requête, puis délègue le calcul et le formatage au service de paiement. Aucune donnée n'est modifiée ni stockée en session : le résultat sert uniquement à rafraîchir l'affichage côté client.

Route : /company/calculate-amount (POST), nom company_calculate_amount.

Annule volontairement le tunnel d'inscription en cours.

Vide les données du parcours stockées en session et informe l'utilisateur. Le compte utilisateur éventuellement créé à l'étape 1 et déjà persisté en base n'est pas supprimé.

Route : /company/cancel (POST), nom company_registration_cancel.

Étape 5 du tunnel : affiche le récapitulatif final de l'inscription.

Relit les données d'entreprise et d'utilisateur conservées en session et les fusionne en injectant l'email et le nom du contact dans le tableau transmis au template. Malgré son intitulé, la méthode n'effectue aucun traitement final : la création effective de l'entreprise est réalisée par CompanyRegistrationController::paymentProcess() lors du choix du moyen de paiement. Aucune vérification de présence des données n'est faite, la page peut donc être atteinte avec un contexte vide.

Route : /company/confirmation (GET, POST), nom company_confirmation.

Si la session porte djomy_retry_payment_id et que le paiement correspondant est encore en attente, il est transmis au template pour proposer de relancer le paiement en ligne.

Le paiement d'inscription mémorisé sous registration_payment_id en session détermine confirmationState (paid, online_pending ou offline, valeur par défaut) ; contactEmail provient de l'utilisateur du paiement, à défaut des données de session.

Étape 2 du tunnel : collecte les informations de l'entreprise et du contact.

L'accès exige un utilisateur existant ET vérifié, sinon retour à l'étape 1 ; si le compte est déjà rattaché à une entreprise, le parcours est interrompu au profit du tableau de bord. Les données de l'utilisateur sont poussées en session par le service d'inscription, et le formulaire est pré-alimenté avec le contenu déjà présent sous la clé de session company_registration, complété de l'email et du nom du contact. À la soumission valide, la position et le téléphone du contact sont écrits sur l'entité User et immédiatement persistés, tandis qu'un objet Company est seulement hydraté puis stocké en session — l'entreprise n'est pas encore enregistrée en base à ce stade.

Route : /company/details/{user_id} (GET, POST), nom company_details.

Protégée par le jeton CSRF djomy_retry. Le paiement est celui mémorisé en session sous djomy_retry_payment_id ; il doit être en attente et provenir de Djomy ou d'un règlement manuel. La relance passe par DjomyCheckoutService::start() : l'ancienne transaction est relue auprès de Djomy (SUCCESS valide le paiement sans nouvelle transaction ; PENDING démarré depuis moins de dix minutes ou une erreur de lecture refusent le réessai ; sinon la nouvelle transaction est ouverte). Elle porte une référence distincte (BCARD-PAY-<id>-R<timestamp>) et un nouveau jeton de retour ; les références de l'ancienne ne sont remplacées qu'en cas de succès de l'appel Djomy.

Route : /company/payment/djomy/retry (POST), nom company_registration_djomy_retry.

Le paiement est retrouvé par son jeton de retour aléatoire {token} (404 s'il est inconnu, ou si le paiement n'est pas Djomy ou n'a pas d'identifiant de transaction). S'il est déjà encaissé, l'utilisateur est simplement redirigé. Sinon le statut est relu auprès de Djomy : seul SUCCESS fait foi (le montant payé n'est pas fiable) et valide le paiement via SubscriptionPaymentService::markPaymentCompleted() ; FAILED et CANCELLED laissent l'abonnement en attente ; tout autre statut ou une erreur de lecture annonce un traitement en cours (le webhook finalisera). djomy_retry_payment_id n'est maintenu en session que si elle porte déjà cette valeur, c'est-à-dire si c'est la session qui a démarré le paiement.

Route : /company/payment/djomy/return/{token} (GET), nom company_registration_djomy_return.

Étape 4 du tunnel : récapitule la commande avant le choix du moyen de paiement.

Les données d'abonnement sont relues en session ; leur absence interrompt le parcours et renvoie à l'étape 1. Le nom du plan est résolu depuis son identifiant (repli sur « Entreprise » si le plan n'est plus trouvé) et le montant est formaté en francs guinéens (séparateur décimal virgule, séparateur de milliers espace, suffixe GNF). Le téléphone de contact saisi à l'étape 2 est transmis pour préremplir le champ du paiement en ligne, dont le bloc n'est affiché que si Djomy est configuré. Aucune donnée n'est modifiée ni persistée.

Route : /company/payment (GET, POST), nom company_payment.

Si les données de session ont été vidées parce que l'inscription est déjà enregistrée (retour arrière depuis Djomy, rechargement), le récapitulatif est reconstruit depuis le paiement en attente mémorisé en session (voir CompanyRegistrationController::findSessionPendingPayment()). La réponse n'est jamais mise en cache par le navigateur.

Le jeton CSRF company_payment_process (champ _token) est contrôlé en premier : s'il est invalide, un message d'erreur est affiché et l'utilisateur revient à company_payment sans rien créer. La valeur djomy crée l'inscription en attente de paiement puis redirige vers la passerelle Djomy (voir CompanyRegistrationController::startDjomyPayment()). La valeur offline finalise l'inscription sans paiement en ligne via CompanyRegistrationService::completeRegistrationPendingPayment() : l'abonnement reste en attente de paiement jusqu'à son activation manuelle par un administrateur, l'email du mot de passe temporaire est envoyé et l'utilisateur est redirigé vers company_confirmation ; en cas d'erreur, un message générique est affiché et l'utilisateur revient à company_payment. Toute autre valeur est journalisée et ramène à la page de paiement avec un message d'erreur.

Route : /company/payment-process (POST), nom company_registration_payment_process.

Étape 1 du tunnel : identifie le contact et crée (ou réutilise) le compte gestionnaire.

En POST, les champs email et name sont lus directement dans la requête et doivent être renseignés ; l'email est ensuite validé par les contraintes NotBlank et Email (la contrainte BusinessEmail, qui interdirait les adresses personnelles, est présente mais commentée). Trois cas se présentent ensuite : un compte existant et déjà vérifié bloque l'inscription ; un compte existant non vérifié est réutilisé, son nom étant mis à jour si nécessaire ; sinon un nouvel utilisateur est créé avec le rôle ROLE_MANAGER et un mot de passe temporaire aléatoire haché. La création ou la mise à jour est tracée au journal d'audit, puis un code de vérification est envoyé par email. Toute exception pendant cette phase est écrite dans le journal PHP et convertie en message flash, le formulaire étant alors réaffiché.

Route : /company/register (GET, POST), nom company_register.

Refuse l'envoi si l'utilisateur est introuvable (retour à l'étape 1), s'il est déjà vérifié (passage à l'étape des informations d'entreprise) ou si le délai anti-spam de EmailVerificationService::canResendCode() n'est pas écoulé. Les échecs d'envoi sont silencieusement écrits dans le journal PHP : une exception applicative produit en plus un message flash d'erreur, tandis qu'une erreur de transport n'est que journalisée, l'utilisateur voyant alors potentiellement un message de succès trompeur.

Route : /company/resend-verification/{user_id} (GET, POST), nom company_resend_verification.

Étape 3 du tunnel : choix du cycle de facturation de l'abonnement « Entreprise ».

L'effectif est repris des données d'entreprise en session (1 par défaut) et sert à dimensionner le formulaire. Seul le plan nommé « Entreprise » et actif est proposé ; s'il est absent du catalogue, un message d'erreur est affiché et l'utilisateur est renvoyé vers company_details — redirection générée sans le paramètre user_id, ce qui peut échouer si la route l'exige. À la soumission valide, le montant total est calculé par le service de paiement à partir du plan, du cycle de facturation et de l'effectif, affecté à l'abonnement, puis l'ensemble est stocké en session avant de passer au paiement. Comme à l'étape 2, aucun abonnement n'est persisté en base ici.

Route : /company/subscription (GET, POST), nom company_subscription.

L'utilisateur est identifié par le paramètre d'URL {user_id} : s'il est introuvable, retour à l'étape 1 ; s'il est déjà vérifié, le parcours saute directement à l'étape des informations d'entreprise. En POST, un code vide produit un message d'erreur et le réaffichage du formulaire ; un code correct fait passer à company_details, un code invalide ou expiré n'affiche qu'un message flash sans limitation du nombre de tentatives. Aucun contrôle d'accès ne protège cette route : le seul identifiant numérique de l'utilisateur suffit à y accéder.

Route : /company/verify-email/{user_id} (GET, POST), nom company_verify_email.