Effectuer un paiement

Un paiement est l'opération principale : une vente, un remboursement, une pré-autorisation ou une finalisation. Ils passent tous par une seule méthode — sendPaymentRequest — et vous sélectionnez le type de paiement avec le champ paymentType. Ce guide couvre le paiement classique ; les variantes diffèrent uniquement par le paymentType et sont mentionnées à la fin.

Prérequis : une session active. Voir Cycle de vie de la session et connexion — sans une connexion réussie, une demande de paiement est ignorée.

L'appel

viewModelScope.launch {
    clientSDK.sendPaymentRequest(
        RetailerMessageArguments.PaymentRequestMessageArguments
            .RegularPaymentRequestMessageArguments(
                saleTransactionId = "Sale001",
                paymentAmounts = PaymentAmounts(
                    currency = "EUR",
                    amount = BigDecimal("10.00")
                ),
                paymentType = PaymentType.NORMAL
            )
    )
}

Les trois champs dont vous avez besoin :

• saleTransactionId — votre référence pour la vente. Doit être alphanumérique et contenir 35 caractères ou moins. Si vous la dérivez d'un UUID, supprimez les tirets — un UUID brut fait 36 caractères et sera rejeté.
• paymentAmounts — un PaymentAmounts. Au minimum, currency (doit correspondre à la devise configurée sur le terminal) et amount (un BigDecimal). Il peut aussi contenir tipAmount, cashbackAmount et paidAmount — voir la référence API pour la liste complète des champs.
• paymentType — un PaymentType. NORMAL pour une vente standard.

Lire le résultat

Le résultat arrive dans votre intercepteur sous forme d'un sous-type de RetailerPaymentResponse :

when (message) {
    is SuccessRetailerPaymentResponse -> { /* approuvé — lire les données POI, les montants */ }
    is ErrorRetailerPaymentResponse   -> { /* refusé ou échoué */ }
    is PartialRetailerPaymentResponse -> { /* résultat partiel — gérer explicitement */ }
    is RetailerDisplayRequest         -> { /* mise à jour de progression pendant le traitement */ }
}

Gérez les résultats du super-type, pas seulement le succès — voir Comment fonctionne le modèle de message pour comprendre pourquoi. Les messages RetailerDisplayRequest arrivent pendant le traitement pour indiquer ce que fait le terminal ; ils ne représentent pas le résultat final.

Le POITransactionID est important plus tard. Une réponse de paiement réussie contient un POITransactionID dans ses données POI. Si vous devez annuler ce paiement, enregistrez cet ID maintenant — l'annulation en a besoin. Voir Guide : annuler une transaction.

Les variantes de paiement

Vous n'appelez pas une méthode différente pour les remboursements ou les pré-autorisations — vous changez le paymentType. Les mêmes types de requête et de réponse s'appliquent ; il n'existe pas de sous-types de réponse séparés pour remboursement/pré-autorisation. Un RetailerDisplayRequest pendant le traitement indique quelle opération est en cours.

PaymentType définit 13 valeurs au total (y compris les paiements en plusieurs fois, récurrents, avances de fonds, et autres). Les quatre ci-dessus sont les plus courantes ; l'énumération complète est dans la référence API. Utilisez la constante d'énumération exacte — les valeurs sont en majuscules (NORMAL, pas Normal).

Annuler un paiement en cours

Un paiement qui a démarré mais n'a pas encore atteint l'autorisation de l'hôte peut être annulé avec sendAbortRequest(). Après l'autorisation, il est trop tard pour annuler — utilisez plutôt une annulation. Voir Guide : annuler une transaction et Dépannage : l'annulation n'a aucun effet après autorisation.

Articles connexes

• Démarrage rapide — le parcours du premier paiement.
• Comment fonctionne le modèle de message — gérer correctement la réponse.
• Guide : annuler une transaction — annuler un paiement effectué.
• Guide : acquisition de carte et paiements en deux étapes — lecture préalable de la carte, puis finalisation.
• Référence API (sdk-doc.zip) — liste complète des champs PaymentAmounts et énumération complète PaymentType.