Répartition des paiements par carte dans les SDK
Configurer et utiliser la répartition de deux cartes via le widget ou les éléments de paiement DEUNA sur les SDK pris en charge.
Sur cette page
La répartition des paiements par carte permet à un client de répartir une commande sur plusieurs cartes dans une expérience DEUNA prise en charge. Les exemples publics de SDK actuels configurent deux cartes avec behavior.paymentMethods.creditCard.splitPayments.maxCards.
Voir Split Payments dans le checkout#
La démo suivante montre un client répartissant une commande sur deux cartes dans l'expérience de paiement DEUNA :
Utilisez la démo pour une orientation visuelle. Votre backend doit toujours concilier chaque tentative et vérifier l’état global de la commande avant son exécution.
Flux de paiement#
Activer le comportement#
await DeunaSDK.initPaymentWidget({
orderToken,
behavior: {
paymentMethods: {
creditCard: {
splitPayments: {maxCards: 2},
},
},
},
callbacks,
});await deunaSDK.initPaymentWidget({
orderToken,
mode: 'modal',
behavior: {
paymentMethods: {
creditCard: {
splitPayments: {maxCards: 2},
},
},
},
callbacks,
});let behavior: Json = [
"paymentMethods": [
"creditCard": [
"splitPayments": ["maxCards": 2]
]
]
]
deunaSDK.initPaymentWidget(
orderToken: orderToken,
callbacks: callbacks,
behavior: behavior
)val behavior: Json = mapOf(
"paymentMethods" to mapOf(
"creditCard" to mapOf(
"splitPayments" to mapOf("maxCards" to 2)
)
)
)
deunaSDK.initPaymentWidget(
context = this,
orderToken = orderToken,
callbacks = callbacks,
behavior = behavior
)Web et React Native utilisent l'objet de comportement. iOS et Android acceptent la même forme publique au format JSON. Conserver l'orthographe et le niveau de nidification exactement tels qu'ils sont affichés.
Événements et callbacks#
| Signal | Utilisation |
|---|---|
onCardBinDetected / onBinDetected | Détecter le BIN de la carte active sans collecter les données de carte brutes. |
onInstallmentSelected | Associer l'option de plan sélectionnée à la carte actuellement configurée. |
paymentMethodSplitPayments | Événement natif pour les éléments indiquant le chemin de paiement divisé. |
paymentProcessing / onPaymentProcessing | Empêcher les actions dupliquées pendant que l'opération combinée est en cours. |
purchase, purchaseError, purchaseRejected | Uniquement pour le cycle de vie du client ; concilier toujours la commande et ses tentatives. |
Ne reconstruire pas le résultat financier en additionnant les événements du client. Utilisez les enregistrements de commande et de transaction de backend actuels.
Gestion des erreurs et récupération#
Les paiements partiels peuvent entraîner un état opérationnel partiel : une tentative peut atteindre un état différent d'une autre. Concevez le chemin de récupération avant d'activer cette fonctionnalité.
| Scénario | Comportement du commerçant |
|---|---|
| La première carte échoue avant que la seconde ne réussisse | Conservez la commande ouverte uniquement si l'état actuel de la commande permet une autre tentative. |
| Une carte réussit et l'autre échoue | Reconciliez les deux tentatives ; ne soumettez pas un nouveau paiement complet sans vérification. |
| Le client quitte pendant le processus | Récupérez la commande avant de restaurer les options de paiement. |
| Le client perd la connexion | Traitez le résultat comme inconnu jusqu'à ce que le backend réponde. |
| Double tap ou tentative | Réutilisez vos contrôles opérationnels et votre stratégie d'empotement documentée. |
Matrice de test#
- Deux cartes avec une allocation identique et une précision de devise prise en charge.
- Installments sur une carte éligible et pas d'installments sur une carte non éligible.
- Refus sur la première et la deuxième carte séparément.
- Arrière-plan de l'application, rafraîchissement ou perte de réseau entre les cartes.
- Le client quitte après avoir entré une carte.
- Autorisation lente et soumissions répétées.
- WebHook final et état de l'API correspondant à l'écran de confirmation du client.