SDK Web em um WebView móvel

Utilize um WebView personalizado somente quando sua aplicação precisa hospedar um checkout web existente e de propriedade do comerciante. Para uma nova integração móvel, prefira a solução mantida iOS, Android, ou Reagir nativo SDK: Estes SDKs já implementam a ponte DEUNA WebView e o ciclo de vida de ações externas.

ArquiteturaPerguntar à Athia sobre isto#

Veja o padrão de wrapper WebViewPerguntar à Athia sobre isto#

Este passo a passo mostra um checkout na web do comerciante carregado dentro de um iOS WebView. O wrapper nativo troca mensagens com a página de checkout enquanto o DEUNA Web SDK renderiza a experiência de pagamento:

O vídeo demonstra o padrão de apresentação. Os detalhes da IU podem mudar; use a arquitetura, os limites de segurança e os requisitos de plataforma abaixo como contrato de implementação.

Capacidades necessárias do WebViewPerguntar à Athia sobre isto#

Definir uma ponte mínimaPerguntar à Athia sobre isto#

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
}

Na fronteira nativa, parse JSON com um esquema rigoroso, rejeitar versões e tipos de mensagens desconhecidos, limitar o tamanho da mensagem e ignorar mensagens de páginas de nível superior inesperadas. Nunca expor um dispatcher nativo genérico para JavaScript.

Enviar resultados do SDKPerguntar à Athia sobre isto#

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 apenas os campos que a aplicação nativa precisa. Não transmitir tokens de pedido, tokens de carteira, dados de cartão, objetos de cliente completos ou payloads de eventos brutos arbitrários.

Janelas e redirecionamentos externosPerguntar à Athia sobre isto#

O Web SDK emite eventos de ciclo de vida para pop-ups externos suportados. Sua WebView deve interceptar window.open ou solicitações de nova janela e apresentar o alvo sem relatar incorretamente que ele foi fechado imediatamente.

• Permitir apenas https URLs cujo host corresponda aos seus destinos de autenticação ou pagamento aprovados.
• Preferir uma superfície de navegador isolada para conteúdo de terceiros; não injetar a ponte do comerciante em uma página do emissor ou provedor.
• Rastrear a superfície externa independentemente da WebView do checkout.
• Ao finalizar ou retornar, retome o processo de checkout e obtenha o estado do pedido.
• Não suprima globalmente os erros de timeout. Um timeout pode indicar uma ação incompleta; reconcilie e, em seguida, apresente um caminho de recuperação adequado.

Os repositórios do SDK incluem wrappers de referência mantidos para Examples/checkout-web-wrapper para iOS e examples/checkout-web-wrapper para Android.

Verificação da plataformaPerguntar à Athia sobre isto#

Interface responsiva e acessívelPerguntar à Athia sobre isto#

• Respeite as margens de segurança e o teclado na tela.
• Utilize a largura total disponível e altura dinâmica da viewport; evite um WebView de tamanho fixo, semelhante ao de desktop.
• Mantenha os controles de fechamento nativos fora do conteúdo de pagamento, mas acessíveis através de tecnologias assistivas.
• Anuncie a navegação e os erros, e restaure o foco após o fechamento de uma superfície externa.
• Teste a rotação, a tela dividida, texto grande, leitores de tela, redes lentas e o fechamento em segundo plano do aplicativo.

Matriz de testesPerguntar à Athia sobre isto#

• Sucesso, falha e encerramento do cliente no pagamento.
• 3DS sem atrito e com desafios.
• Sucesso, cancelamento e timeout do provedor no APM.
• Janela externa fechada pelo cliente.
• Aplicativo fechado em segundo plano e posteriormente retomado.
• Perda de rede antes e depois da submissão.
• Navegação não confiável e mensagens de ponte malformadas são rejeitadas.
• O estado do backend é correto após qualquer resultado ambíguo do cliente.

Referências relacionadasPerguntar à Athia sobre isto#