Implementación de una puerta de enlace P2P Operaciones de transferencia de tarjeta a tarjeta

Para mi proyecto, necesitaba darme cuenta de la capacidad de transferir de una tarjeta a otra. Para una conexión oficial a la interfaz de cualquier banco, es necesario celebrar un acuerdo y cumplir una serie de condiciones. Por lo tanto, se decidió hacer una entrada a la página pública del banco. Para estos fines, se seleccionaron dos bancos, Tinkoff y BIN Bank, que brindan la oportunidad de transferir a "sus" tarjetas sin comisión. Puede encontrar más información sobre aranceles y restricciones sobre transferencias en las páginas relevantes de los bancos. Este artículo describe brevemente el funcionamiento de una puerta de enlace que implementa la funcionalidad de aceptar pagos a una tarjeta.

Es necesario implementar una transferencia desde cualquier tarjeta a una tarjeta preseleccionada, con soporte para el procedimiento de autorización 3DSecure. 3DSecure es un protocolo de autorización de usuario seguro para operaciones CNP (sin la presencia de una tarjeta). Puede leer más en sitios especializados, el siguiente diagrama muestra un diagrama simplificado de cómo funciona esto desde el punto de vista del usuario.

imagen

La imagen muestra un mecanismo simplificado para autorizar una transacción, lo que sucede "bajo el capó" cuando realiza una operación de pago o transferencia de una tarjeta a otra e ingresa un código SMS para confirmarlo.

Consideremos paso a paso:

  1. Ingrese los detalles y la cantidad de la tarjeta, y envíela al sitio web del banco.
  2. El banco utiliza un servicio especializado (Merchant Plug-In MPI), que genera una solicitud PaReq especial, que es XML con firma digital, que contiene parámetros de transacción, así como datos a los que se debe enviar esta solicitud (Access Control Server ACS) y dónde enviarla. respuesta de autorización (PaRes).
  3. El banco devuelve al usuario una página que contiene información de MPI y redirige automáticamente el navegador a la página ACS del banco que emitió la tarjeta del usuario. Se le muestra al usuario una página para ingresar un código de SMS y se envía un SMS al número de teléfono registrado en el banco emisor.
  4. Después de ingresar el código SMS, el servidor ACS genera una página con una respuesta de autorización (PaRes), redirigiendo al usuario a la página MPI para completar la operación o negarse a realizarla.

Para una comprensión más profunda del proceso, lea los documentos relevantes de Visa o Mastercard, este nivel es suficiente para resolver este problema.

Para garantizar un funcionamiento perfecto de la puerta de enlace de modo que los oídos del sitio web a través de los cuales la traducción no sobresalga, es necesario integrarse en el proceso de redirección del navegador entre MPI y ACS. Para hacer esto, reemplace la dirección (TermUrl) recibida de MPI. Esta es la dirección a la que se redirigirá PaRes después de que el usuario complete la autorización, ya que TermUrl, la dirección de la puerta de enlace se ingresa en la solicitud. Esto permitirá que la puerta de enlace reciba una respuesta (RaRes) para enviarla al servidor MPI y, después de procesar la respuesta MPI, dirija al usuario a la página de finalización exitosa o no exitosa de la transacción.

La puerta de enlace funciona entre el navegador del usuario y la página del banco, implementa funciones de entrada / salida que emulan la página del banco, complementa y modifica datos, y procesa respuestas y errores de los servicios bancarios.

El protocolo de interacción con cada uno de los bancos se aclaró manualmente mediante la interacción de ingeniería inversa entre el navegador y el sitio web del banco, en general, la lógica es la misma, la diferencia en las variables y los métodos de transferencia. En general, esto es un cuello de botella, y la funcionalidad del software depende de la inmutabilidad de la API, tan pronto como el banco cambie la operación del servicio, la lógica de la puerta de enlace también tendrá que cambiarse.

Consideremos con más detalle la lógica del trabajo.

Para garantizar las operaciones en la puerta de enlace, se implementa una página de pago, cuya llamada se realiza en la dirección:

http://< >/pay/page?payid=123456&sum=100&text=Test 

La URL contiene las siguientes variables:

payid : se requiere ID de transacción para identificar los resultados de la solicitud de pago después de que se complete la transacción;
sum : el monto de la transacción;
texto - campo de información "Propósito del pago".



Después de completar los datos de la tarjeta, de acuerdo con los términos de ejecución, se realiza una solicitud de comisión para la operación. El tamaño de la comisión y el banco (uno de los dos Tinkoff y BIN) a través del cual se realizará la transferencia depende de la tarjeta especificada en la configuración de la puerta de enlace como el receptor de la transferencia y la disponibilidad del servicio bancario. Se implementa un mecanismo simple para el enrutamiento y el manejo de errores en la puerta de enlace: Tinkoff siempre se selecciona, si la página del banco no está disponible, entonces se selecciona la página BIN Bank.

Después de hacer clic en el botón de transferencia, el sistema se redirige a la página del banco emisor que emitió la tarjeta (ACS), desde donde se realizará la operación de débito. La puerta de enlace solicitará los parámetros de PaReq de MPI, reemplazará TermUrl y enviará los datos al usuario, después de recordar los parámetros de la transacción en el caché (Redis).

Una vez completada la autorización, PaRes irá a la puerta de enlace y, en función de los datos de caché, los reenviará al MPI correspondiente, procesará la respuesta y redirigirá al usuario a una de las páginas (ERROR_PAGE, SUCCESS_PAGE) especificadas en la configuración de la puerta de enlace.

La URL de la página para completar con éxito la operación contiene la variable payid, que transmite los resultados de la operación en forma de JWT con firma digital.

JWT ejemplo:

 eyJhbGciOiJIUzUxMiJ9.eyJqdGkiOiI2Njk2NzFlYi1mYmZlLTVlMTMtYTdkZi05NDEwZjg1N2U5ODkiLCJpYXQiOjE1NzE5MDg5MjgsInN1YiI6ImZpeGVkIiwiaXNzIjoicnUucGhvbmU0cGF5IiwicGF5X2lkIjoiMTIzNDUiLCJzdW0iOiIxMDAuMCIsInRyYW5zYWN0aW9uX2lkIjoiODY4MTE5ODYzIn0.c-IK3FowoR_tVe3-cpT7-rmA4EQhYy8rZkWrWASHZlc0ZzzpQont5XriCSzuDaY7jf7iIC8ZAxknAMwmTNmAHg 



Al verificar el contenido de JWT, puede obtener información confiable sobre el éxito de la operación, el token JWT realiza una función similar a PaReq y proporciona la capacidad de integrarse con un sistema externo.

Esta solución es un prototipo de una pasarela de pago, con la que puede implementar la adquisición de Internet (aceptar pagos con tarjeta) en su sitio web o página de red social. Puede parametrizar su página de pago o escribir la suya, modificar creativamente el software, lo principal es transferir la cantidad y la identificación de la operación a la entrada y verificar en la salida que nadie más ha cambiado creativamente. Las fuentes y ejemplos de trabajo están disponibles en github .

También hay una puerta de enlace para reponer su billetera VK.pay, que también se puede usar como una puerta de enlace de pago. En general, implementa los mismos principios, Selenium se utilizó para implementar parte de la funcionalidad, con la ayuda de la cual se implementa la autorización en el sitio y la autorización para acceder a la billetera.

¡IMPORTANTE! Cualquier transacción de Internet es potencialmente peligrosa, sus datos pueden ser robados, debe tomar precauciones al realizar transacciones de Internet.

¡IMPORTANTE! Se otorga responsabilidad penal por el robo de fondos de las tarjetas bancarias de otra persona (artículos 159.3, 159.6 del Código Penal de la Federación de Rusia) .

Source: https://habr.com/ru/post/474298/


All Articles