SDK web dans un WebView mobile

Utiliser un WebView personnalisé uniquement lorsque votre application doit héberger un point de vente web existant appartenant au commerçant. Pour une nouvelle intégration mobile, privilégiez la solution maintenue iOS, Android, ou Réagir à l'initié SDK : Ces SDK implémentent déjà le pont DEUNA WebView et le cycle de vie des actions externes.

ArchitectureInterroger Athia à ce sujet#

Voir le modèle de wrapper WebViewInterroger Athia à ce sujet#

Cette procédure pas à pas montre un paiement Web marchand chargé dans une WebView iOS. Le wrapper natif échange des messages avec la page de paiement tandis que DEUNA Web SDK restitue l'expérience de paiement :

La vidéo montre le modèle de présentation. Les détails de l'interface utilisateur peuvent changer ; utilisez l'architecture, les limites de sécurité et les exigences de plate-forme ci-dessous comme contrat de mise en œuvre.

Capacités WebView requisesInterroger Athia à ce sujet#

Définir un pont minimalInterroger Athia à ce sujet#

type NativeMessage = {
  version: 1;
  type: 'success' | 'error' | 'closed' | 'event';
  widget: 'payment' | 'elements' | 'voucher' | 'nextAction';
  data?: unknown;
};

function postToNative(message: NativeMessage) {
  const body = JSON.stringify(message);
  window.webkit?.messageHandlers.deunaPayment?.postMessage(body); // iOS
  window.deunaPayment?.postMessage(body);                         // Android
  window.ReactNativeWebView?.postMessage(body);                   // React Native
}

Au niveau natif, analyser les données JSON avec un schéma strict, rejeter les versions et types de messages inconnus, limiter la taille des messages et ignorer les messages provenant d'une page de niveau supérieur inattendue. Ne jamais exposer un dispatcher de méthode natif générique au JavaScript.

Transmettre les résultats de l'SDKInterroger Athia à ce sujet#

await DeunaSDK.initPaymentWidget({
  orderToken,
  callbacks: {
    onSuccess: (data) => postToNative({version: 1, type: 'success', widget: 'payment', data}),
    onError: (data) => postToNative({version: 1, type: 'error', widget: 'payment', data}),
    onClosed: (action) => postToNative({version: 1, type: 'closed', widget: 'payment', data: {action}}),
    onEventDispatch: (event) => postToNative({
      version: 1,
      type: 'event',
      widget: 'payment',
      data: {event},
    }),
  },
});

Transmettre uniquement les champs dont l'application native a besoin. Ne pas transmettre les tokens de commande, les tokens de portefeuille, les données de carte, les objets clients complets ou des charges de travail d'événements brutes arbitraires.

Fenêtres et redirections externesInterroger Athia à ce sujet#

Le Web SDK émet des événements de cycle de vie pour les pop-ups externes pris en charge. Votre WebView doit intercepter window.open ou les requêtes de nouvelles fenêtres et afficher la cible sans signaler de manière incorrecte qu'elle a été fermée immédiatement.

• Autoriser uniquement https Les URL dont l'hôte correspond à vos destinations d'authentification ou de paiement approuvées.
• Privilégier une surface de navigateur isolée pour le contenu tiers ; ne pas injecter le pont du commerçant sur une page d'émetteur ou de fournisseur.
• Suivre la surface externe indépendamment du WebView de la page de paiement.
• Lors de la fermeture ou de la reprise, relancez le processus de paiement et récupérez l'état de la commande.
• Ne supprimez pas les erreurs de timeout de manière globale. Un timeout peut indiquer une action incomplète ; vérifiez, puis affichez un chemin de récupération approprié.

Les dépôts SDK incluent des wrappers de référence maintenus pour Examples/checkout-web-wrapper iOS et examples/checkout-web-wrapper Android.

Vérification de la plateformeInterroger Athia à ce sujet#

Présentation réactive et accessibleInterroger Athia à ce sujet#

• Respectez les marges de sécurité et le clavier sur écran.
• Utiliser toute la largeur disponible et une hauteur de fenêtre dynamique. Éviter une WebView de taille fixe.
• Conserver les contrôles de fermeture natifs en dehors du contenu de paiement, mais accessibles aux technologies d'assistance.
• Annoncer la navigation et les erreurs, et restaurer le focus après la fermeture d'une surface externe.
• Tester la rotation, le mode split-screen, le grand texte, les lecteurs d'écran, les réseaux lents et la mise en arrière-plan de l'application.

Matrice de testInterroger Athia à ce sujet#

• Succès, refus et fermeture du paiement par le client.
• 3DS sans friction et avec des défis.
• Succès, annulation et timeout du fournisseur pour APM.
• Fenêtre externe fermée par le client.
• Application mise en arrière-plan et reprise ultérieure.
• Perte de connexion avant et après la soumission.
• Navigation non fiable et messages de pont malformés sont rejetés.
• L'état du backend est correct après chaque résultat client ambigu.

Références connexesInterroger Athia à ce sujet#