SDK web en un WebView móvil

Utilice un WebView personalizado solo cuando su aplicación debe hospedar un checkout web existente propiedad del comerciante. Para una nueva integración móvil, prefiera el SDK iOS, androideo Reaccionar nativo ; esos SDK ya implementan el puente WebView de DEUNA y el ciclo de vida de la acción externa.

ArquitecturaPreguntar a Athia sobre esto#

Ver el patrón contenedor WebViewPreguntar a Athia sobre esto#

Este tutorial muestra el pago web de un comerciante cargado dentro de un WebView de iOS. El contenedor nativo intercambia mensajes con la página de pago mientras DEUNA Web SDK ofrece la experiencia de pago:

El vídeo muestra el patrón de presentación. Los detalles de la interfaz de usuario pueden cambiar; Utilice la arquitectura, los límites de seguridad y los requisitos de plataforma a continuación como contrato de implementación.

Capacidades requeridas del WebViewPreguntar a Athia sobre esto#

Definir un puente mínimoPreguntar a Athia sobre esto#

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
}

En el límite nativo, parsear JSON con un esquema estricto, rechazar versiones y tipos de mensajes desconocidos, limitar el tamaño del mensaje e ignorar mensajes de una página de nivel superior inesperada. Nunca exponga un dispatcher nativo genérico a JavaScript.

Enviar resultados del SDKPreguntar a Athia sobre esto#

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},
    }),
  },
});

Enviar únicamente los campos que necesita la aplicación nativa. No transmitir tokens de pedido, tokens de wallet, datos de tarjeta, objetos de cliente completos o payloads de eventos brutos arbitrarios.

Ventanas y redirecciones externasPreguntar a Athia sobre esto#

El Web SDK emite eventos de ciclo de vida para popups externos compatibles. Su WebView debe interceptar window.open o solicitudes de nuevas ventanas y presentarlas sin informar erróneamente que se han cerrado inmediatamente.

• Permitir únicamente https URLs cuyo host coincida con sus destinos de autenticación o pago autorizados.
• Prefiera una superficie de navegador aislada para el contenido de terceros; no inyecte el puente del comerciante en una página del emisor o proveedor.
• Rastrear la superficie externa de forma independiente del WebView del checkout.
• Al cerrar o devolver, reanudar el checkout y recuperar el estado del pedido.
• No suprimir los errores de tiempo de espera globalmente. Un tiempo de espera puede representar una acción incompleta; reconciliar y luego mostrar una ruta de recuperación adecuada.

Los repositorios del SDK incluyen envoltorios de referencia mantenidos en Examples/checkout-web-wrapper para iOS y examples/checkout-web-wrapper para Android.

Lista de verificación de la plataformaPreguntar a Athia sobre esto#

Presentación adaptable y accesiblePreguntar a Athia sobre esto#

• Respete los márgenes seguros y el teclado en pantalla.
• Utilice el ancho disponible completo y la altura del viewport dinámica; evite un WebView de tamaño de escritorio fijo.
• Mantenga los controles nativos de cierre fuera del contenido de pago, pero accesibles a través de tecnologías de asistencia.
• Anuncie la navegación y los errores, y restaure el foco después de que se cierre una superficie externa.
• Pruebe la rotación, la pantalla dividida, el texto grande, los lectores de pantalla, las redes lentas y el cierre en segundo plano de la aplicación.

Matriz de pruebasPreguntar a Athia sobre esto#

• Éxito, rechazo y cierre del cliente para la tarjeta.
• 3DS sin fricciones y desafiado.
• Éxito, cancelación y tiempo de espera del proveedor para la redirección de APM.
• La ventana externa cerrada por el cliente.
• Aplicación en segundo plano y posterior reanudación.
• Pérdida de red antes y después de la presentación.
• La navegación no confiable y los mensajes de puente malformados son rechazados.
• El estado del backend es correcto después de cada resultado ambiguo del cliente.

Referencias relacionadasPreguntar a Athia sobre esto#