Aplicaciones móviles (iOS / Android)

No existe un SDK móvil de ROKI. Una app móvil se integra con el mismo flujo de checkout alojado que la web, con tres restricciones propias de lo móvil y fáciles de equivocar.

18.1 La llave secreta nunca viaja dentro de la app

Un binario móvil se puede descompilar: de cualquier APK o IPA se pueden extraer las cadenas de texto, y la ofuscación solo lo hace más lento. Una sk_live_ filtrada le permite a cualquiera crear pagos como el comercio y leer todos los pagos que tiene. La app nunca debe llamar directamente a la API de ROKI.

La topología correcta agrega un salto:

Mobile app  -->  Merchant backend  --POST /payments-->  ROKI
                 (holds the secret key)
            <--  returns only { payment_id, checkout_url }

La app recibe el checkout_url y nada más. El backend se queda con la llave, recibe el webhook y es dueño del estado del pedido.

18.2 Abrí el checkout en el navegador del sistema, no en un WebView

Usá SFSafariViewController en iOS y Chrome Custom Tabs en Android. No uses un WKWebView / WebView pelado.

Cuatro razones por las que esto importa en una página de pago:

1. Los desafíos de 3-D Secure los renderiza el banco emisor, y muchos emisores bloquean o se comportan mal dentro de WebViews embebidos.
2. Los gestores de contraseñas y el autocompletado no funcionan en un WebView pelado, lo que aumenta la fricción al ingresar la tarjeta y el abandono.
3. El cliente no puede ver la barra de URL ni el candado, así que no puede verificar que está en un dominio de pago legítimo - un problema real de confianza a la hora de teclear un número de tarjeta.
4. El navegador del sistema comparte su almacén de cookies y su postura de seguridad, así que el checkout se comporta como ROKI lo probó.

18.3 Volver a la app: solo Universal Links / App Links

Verificado contra la API en producción: success_url y cancel_url aceptan solo URLs http/https. Los esquemas personalizados se rechazan:

O sea que la ruta de retorno tiene que ser una URL https que la app reclame mediante Universal Links (iOS) o App Links (Android). Esa misma URL debería mostrar una página web normal para los clientes que no tienen la app instalada.

18.4 Confirmar el pago dentro de la app

La regla de 9.3 es todavía más importante en móvil, porque el viaje de vuelta es frágil: el cliente puede cambiarse de app, perder conexión o cerrar la hoja del navegador antes de que se dispare la redirección.

La app nunca debe tomar el retorno como confirmación, y nunca debe preguntarle a ROKI directamente. En vez de eso:

1. El backend recibe el webhook payment.approved y actualiza el pedido.
2. La app le consulta periódicamente a su propio backend (o recibe de él una notificación push) el estado del pedido.
3. Si la hoja del navegador se cierra sin redirección, la app igual consulta - bien puede ser que el pago haya salido bien.

18.5 Lo que hoy no existe

No hay SDK móvil, no hay hoja de pago nativa y no hay soporte documentado para Apple Pay ni Google Pay. El SDK de campos de tarjeta embebidos que está en el roadmap está orientado al navegador; una app móvil que quiera captura de tarjeta dentro de su propia interfaz hoy no tiene un camino soportado y tiene que usar el checkout alojado.