BCard - Documentation technique

MobilePaymentService
in package

Briques communes des endpoints de paiement de l'API mobile (Djomy).

Regroupe ce que partagent l'abonnement Pro, les cartes physiques et l'endpoint générique de statut : la relecture du statut d'un paiement auprès de Djomy (avec validation via PaymentFulfillmentService), la construction de la réponse de démarrage et la traduction d'un échec de démarrage en réponse HTTP. Les contrôleurs gardent la création des entités et la propriété des ressources.

Table of Contents

Constants

STATUS_COMPLETED  : mixed = 'COMPLETED'
STATUS_FAILED  : mixed = 'FAILED'
STATUS_PENDING  : mixed = 'PENDING'
MAX_CHECK_AGE_MINUTES  : mixed = 60
Âge (en minutes) au-delà duquel un paiement n'est plus relu chez Djomy depuis l'API : la réconciliation prend le relais.
STATUS_CACHE_TTL  : mixed = 6
Durée de conservation en cache d'un statut Djomy non réussi (l'application interroge toutes les 3 s).

Properties

$cache  : CacheInterface
$djomyService  : DjomyService
$entityManager  : EntityManagerInterface
$fulfillment  : PaymentFulfillmentService
$logger  : LoggerInterface

Methods

__construct()  : mixed
checkStatus()  : array{status: string, check_error: bool}
Relit le statut d'un paiement Djomy et le valide si la passerelle confirme le succès.
failureResponse()  : JsonResponse
Traduit un échec de {@see DjomyCheckoutService::start()} en réponse HTTP.
startResponse()  : JsonResponse
Construit la réponse 201 d'un paiement démarré.
statusResponse()  : JsonResponse
Construit la réponse JSON de vérification de statut d'un paiement.

Constants

MAX_CHECK_AGE_MINUTES

Âge (en minutes) au-delà duquel un paiement n'est plus relu chez Djomy depuis l'API : la réconciliation prend le relais.

private mixed MAX_CHECK_AGE_MINUTES = 60

STATUS_CACHE_TTL

Durée de conservation en cache d'un statut Djomy non réussi (l'application interroge toutes les 3 s).

private mixed STATUS_CACHE_TTL = 6

Properties

Methods

__construct()

public __construct(DjomyService $djomyService, PaymentFulfillmentService $fulfillment, LoggerInterface $logger, CacheInterface $cache, EntityManagerInterface $entityManager) : mixed
Parameters
$djomyService : DjomyService

Relit le statut des transactions.

$fulfillment : PaymentFulfillmentService

Valide un paiement réussi (idempotent, avec verrou).

$logger : LoggerInterface

Journalise les anomalies, sans donnée sensible.

$cache : CacheInterface

Cache applicatif des statuts Djomy non réussis (6 s).

$entityManager : EntityManagerInterface

Persiste le dernier statut Djomy relu.

checkStatus()

Relit le statut d'un paiement Djomy et le valide si la passerelle confirme le succès.

public checkStatus(Payment $payment) : array{status: string, check_error: bool}

Un paiement déjà COMPLETED est renvoyé tel quel. Pour un paiement Djomy PENDING ayant une transaction, le statut est relu chez Djomy : seul SUCCESS fait foi, avec la même vérification que le webhook (devise via DjomyService::isSuccessful() et référence marchande désignant ce paiement), puis PaymentFulfillmentService::fulfill() est appelé avec la source api_status. FAILED et CANCELLED donnent FAILED sans rien modifier en base. Tout autre cas donne PENDING. Pour limiter les appels à Djomy, un statut non réussi est mis en cache 6 s par paiement (jamais un SUCCESS), et un paiement démarré depuis plus de 60 minutes (providerStartedAt, à défaut updatedAt) n'est pas relu : il reste PENDING et la réconciliation serveur prend le relais. Une erreur de lecture ou de validation ne lève rien : le résultat est PENDING avec check_error à true (le webhook ou la réconciliation finaliseront).

Parameters
$payment : Payment

Paiement appartenant à l'utilisateur authentifié (contrôlé par l'appelant).

Return values
array{status: string, check_error: bool} —

Statut COMPLETED, PENDING ou FAILED.

failureResponse()

Traduit un échec de {@see DjomyCheckoutService::start()} en réponse HTTP.

public failureResponse(Throwable $e[, Payment|null $payment = null ][, array<string, mixed> $extra = [] ]) : JsonResponse

409 pour un paiement déjà en cours ou déjà payé, 503 si Djomy n'est pas configuré, injoignable ou si la relecture de la transaction précédente échoue, 400 pour les autres refus (téléphone invalide, paiement non payable). Le message vient de DjomyCheckoutService::describeFailure() et error_code porte le motif technique pour l'application. Toute autre exception donne un 500 générique.

Parameters
$e : Throwable

Exception levée pendant le démarrage.

$payment : Payment|null = null

Paiement concerné s'il est persisté : son identifiant est renvoyé dans data pour que l'application puisse interroger le statut.

$extra : array<string, mixed> = []

Identifiants propres au parcours (subscription_id, physical_card_id, order_id).

Return values
JsonResponse —

Réponse {"success":false,"message":…,"error_code":…[,"data":{payment_id,…}]}.

startResponse()

Construit la réponse 201 d'un paiement démarré.

public startResponse(Payment $payment, string $redirectUrl[, array<string, mixed> $extra = [] ]) : JsonResponse
Parameters
$payment : Payment

Paiement dont la transaction Djomy vient d'être ouverte.

$redirectUrl : string

URL de la page de paiement Djomy.

$extra : array<string, mixed> = []

Identifiants propres au parcours (subscription_id, physical_card_id, order_id…).

Return values
JsonResponse —

Réponse 201 {"success":true,"data":{payment_id,…,redirect_url,status,amount,currency}}.

statusResponse()

Construit la réponse JSON de vérification de statut d'un paiement.

public statusResponse(Payment $payment, array{status: string, check_error: bool} $result[, array<string, mixed> $extra = [] ]) : JsonResponse
Parameters
$payment : Payment

Paiement vérifié.

$result : array{status: string, check_error: bool}

Résultat de self::checkStatus().

$extra : array<string, mixed> = []

Champs supplémentaires propres au parcours (physical_card_id…).

Return values
JsonResponse —

{"success":true,"data":{payment_id,status,subscription_status,order_status[,check_error]}} (200).


        
On this page

Search results