Procesamiento de pagos en Android

Esto depende en gran medida del adversario que está proponiendo.

Si por "desenvolver" te refieres a desensamblar y parchar, entonces tienes un modelo de amenaza contra el que no puedes defenderte y aquí es por qué:

Si supones que pueden desensamblar y parchear tu código, básicamente pueden hacer lo que quieran, después de todo, es su aplicación y luego usan su propio código que parece ser el tuyo.

Además, cualquier secreto que pueda usar para verificar una solicitud proveniente de una instancia de SDK válida (por ejemplo, firma de solicitud) puede ser manipulado por ingeniería inversa por un adversario de este tipo.

En definitiva, es la aplicación de los comerciantes y pueden ejecutar el código que deseen y es el dispositivo del consumidor sobre el que no tiene control.

Esto, por cierto, es la razón por la que las aplicaciones de pago son del proveedor de sistemas operativos o de una aplicación separada que está vinculada a la aplicación de los proveedores (por ejemplo, Apple Pay, google wallet, PayPal).

Además, para que quede claro: los dispositivos rooteados pueden muy bien utilizarse para volcar todos los datos en la memoria, por lo que no existe una seguridad completa.

También es digno de mención: cualquier comunicación con su back-end debe estar protegida por TLS, incluida la fijación de certificados dentro de la aplicación para contrarrestar cualquier ataque MITM.

Los detalles de la implementación están fuera de tema aquí y no los cubriré; es posible que tenga más suerte con eso en SO.

  

Si creo una vista personalizada para esta tarea en la biblioteca del SDK, ¿cómo puedo asegurarme de que un comerciante deshonesto no desenvuelva mi biblioteca, la reescriba y reciba mis llamadas de pago al servicio web y registre los datos de seguridad en su base de datos.

Debe comprender una regla muy simple que Raph Koster lo puso muy sucintamente

  

Nunca confíes en el cliente.   Nunca ponga nada en el cliente. El cliente está en manos del enemigo. Nunca jamás olvides esto.

Mientras Raph está hablando de juegos en línea, todavía se aplica a todo lo demás. Especialmente esta parte que mencionaste

  

El objetivo principal es realizar el pago sin dar acceso al comerciante en los detalles de pago: número de tarjeta o CVV.

No puedes evitar eso. Si desarrollo una aplicación con su SDK, puedo recopilar y almacenar cualquier información que desee. Leyendo entre líneas, parece que estás vendiendo tu PCI-DSS en tu SDK, pero tus clientes desarrollarán la aplicación. Comprenda, la gente puede (y lo hace habitualmente) volver a empaquetar aplicaciones de Android todo el tiempo . Es trivial de hacer.

En otras palabras, su modelo de negocio no funcionará. El cliente, por definición, tendrá que recopilar los datos primero y luego pasárselos. Si eligen almacenar esos datos (en una posible violación de PCI-DSS), no puede detenerlos, y estaría en problemas si dicho cliente (s) fuera hackeado y se la robaran.