Integración de pagos con React Native en la aplicación (negro) | Por Gogulbharathisubbaraj | Proyecto de compensación de impuestos | Enero de 2022
Echemos un vistazo a los diversos métodos y enfoques utilizados para implementar el diseño mientras cumplimos con las pautas iniciales establecidas en las siguientes secciones.
en componentes
Como todos sabemos, la componenteización es uno de los principios básicos de la componenteización. reacción, lo que lo convierte en uno de los marcos de referencia para el diseño de front-end. Entonces, la primera tarea aquí es dividir toda la página en pequeños componentes que puedan ejecutarse de forma independiente.
Entonces, a primera vista, dividiríamos aproximadamente la página en componentes como,
- Componentes de cada método de pago (UPI App, UPI Money Collection y Banca por Internet)
- ventana emergente del banco
- Componente de entrada sugerido (para la recopilación de UPI)
Pero el problema con este enfoque es que en cada componente del método de pago, habrá algunas partes del código que se repiten,
- Sección de encabezado y componente de banco
- Lógica para expandir y reducir el contenido del método
Podemos considerar la interfaz de usuario del encabezado como un componente separado incluido en el componente de cada método,
Sin embargo, la lógica de expandir/contraer se repetirá en cada componente, lo que no es una buena solución escalable. React native nos permite pasar componentes como subcomponentes, por lo que podemos usar este enfoque para una solución escalable. Por lo tanto, todo el componente de pago se puede desacoplar en componentes padre-hijo.
El componente principal será responsable de expandir, reducir, seleccionar la cuenta bancaria, y cada componente secundario solo será responsable de la interfaz de usuario para un método de pago específico, métodos de verificación, etc. Así que el código final se ve así,
Con este enfoque, desvinculamos la lógica de la interfaz de usuario, por lo que agregar un nuevo método en el futuro será muy simple: agregue un nuevo componente para pagos y envuélvalo con este componente principal.
más desacoplamiento
Actualmente confiamos en nuestros socios de pago para obtener la aplicación UPI instalada en el dispositivo del usuario. Por lo tanto, en la sección de aplicaciones UPI, la lista de aplicaciones UPI también está separada y diseñada como un componente separado para obtener y mostrar la lista de aplicaciones UPI. De esta manera, en el futuro, si hay algún cambio en el SDK del socio de pago, solo se debe cambiar en ese componente y el componente principal de pago no se verá afectado. Este componente de la aplicación UPI también encapsula la lógica de priorización, que rara vez muestra las aplicaciones priorizadas.
Levante «estado» y use la API de contexto
React recomienda elevar el estado a un ancestro común para que varios componentes puedan compartir datos comunes. También en la página de pago, tenemos muchos estados y datos que administran varios componentes de la interfaz de usuario. Por ejemplo. Método de pago seleccionado, cuenta bancaria seleccionada, recomendaciones UPI, datos de tiempo de inactividad, datos del último pago exitoso, etc.
Pasar estos valores a un solo componente se volvería inmanejable y aumentaría las líneas de código en la página principal. Para superar esto, utilizaremos la API de contexto proporcionada por react-native, que permite compartir datos comunes entre componentes.
Con este enfoque, cada componente se deconstruirá internamente y obtendrá la información que necesita, y no dependerá de la página principal para pasar los accesorios que el componente necesita individualmente.
La función de la página de pago es solo iniciar la transacción en el lado del socio de pago de acuerdo con el método de pago seleccionado y manejar los casos de éxito y error.
manejo de errores
Como se indicó originalmente, queríamos una experiencia de manejo de errores configurable sin lanzamientos de aplicaciones ni inserciones de código. Para hacer esto, alojamos un archivo de configuración en nuestro sistema interno para configurar la experiencia de error para cada código de error del SDK. Veamos la estructura de JSON para una mejor comprensión,
Como podemos ver en cada código, hay campos que describen el mensaje de error a mostrar, así como la etiqueta y la acción del botón.Por ejemplo: para bank_account_invalid
Los usuarios del código verán un mensaje con «Your bank accounts are invalid…
” mensaje y 2 botones que llevan al usuario a add bank
y profile
páginas por separado.
Pero obtener este archivo en la aplicación y buscar códigos de error e información sería una forma ineficiente de hacer las cosas.Aquí usamos nuestro GráficoQL Infraestructura de servidor para hacer el trabajo. Cada vez que el SDK encuentra un error, la aplicación consulta el servidor GraphQL para la acción, que a su vez responde al escenario de error con solo un fragmento JSON.
reporte de error
Con el enfoque anterior, también podemos manejar los errores informados a los canales internos. Una vez que la aplicación informa un error al servidor GraphQL, el servidor envía algunos escenarios de error graves junto con la información del usuario y la sesión a nuestro canal interno para la intervención humana. Sin un servidor GraphQL, este tipo de informe de errores sería una tarea abrumadora. Los errores también se registran y guardan para referencia futura o depuración.
beneficio
Este método de codificación nos ayuda mucho a probar las liberaciones de pagos, ya que podemos probar exhaustivamente los componentes individuales y liberarlos sin errores. Este enfoque también garantiza que no tengamos problemas graves al expandir nuestra nueva página de pago a toda nuestra base de usuarios.
Más tarde, cuando agregamos una nueva opción de pago personalizada de «pagar más tarde», ni siquiera tocamos ningún código existente para adaptar el nuevo método.
Llévalo al siguiente nivel 🚀
Estamos constantemente en contacto con nuestros otros socios de pago para llegar a una solución y esta página se puede ampliar para admitir pagos a través de otros socios.
Agregue la configuración para habilitar y deshabilitar el método por método de pago y por banco, ya que notamos que algunos bancos no admiten el cumplimiento (autenticación de la identidad del usuario) para ciertos métodos.