Elegir un método de integración
Para aceptar pagos de sus pagadores utilizando el MCB Payment Gateway, debe seleccionar un método de integración. Todo esto le permite recopilar detalles de pago del pagador y crear las transacciones necesarias para gestionar el ciclo de vida completo del pedido, desde el inicio de un pago único con la participación del pagador hasta la realización de pagos recurrentes y la provisión de reembolsos, según sea necesario.
Los principales métodos de integración son:
- 3-Party Checkout
Esta integración incluye una interfaz de usuario (UI) de página de pago alojada en el motor de pagos. El motor de pagos proporciona la interfaz de usuario para recopilar todos los detalles de pago directamente del pagador, por lo que no es necesario manejar datos confidenciales de la industria de tarjetas de pago (PCI). La solución es segura y rápida de implementar, pero como utiliza una interfaz de usuario predefinida, plantea algunos límites a su capacidad para controlar la experiencia del usuario.
- Hosted Session
Esta integración le permite definir su propia página de pago para recopilar detalles de pago del pagador. Sin embargo, para lograr costos mínimos de cumplimiento de PCI, la página de pago debe utilizar campos alojados en el motor de pagos. De esa manera, el motor de pagos recopila los datos de pago directamente y usted no necesita manejarlos. La solución es más avanzada que 3-Party Checkout y le permite un control total de la experiencia del usuario. Si desea ofrecer su solución de pago a sus pagadores como una aplicación móvil, puede utilizar el Mobile SDK para implementar la integración de Hosted Session para una aplicación.
- 2-Party merchant hosted
Esta integración le brinda control total sobre la página de pago y la experiencia del usuario. Usted mismo recopila y almacena los datos de pago del pagador. La solución es la más avanzada y la más lenta de implementar, pero permite implementar escenarios complejos.
Debe implementar uno de los métodos de integración anteriores, ya que le permiten implementar transacciones iniciadas por el titular de la tarjeta (CIT) que requieren la participación activa del pagador (para autorizar el pago que desea crear).
Si sus procesos comerciales requieren el procesamiento por lotes de operaciones masivas, por ejemplo CAPTURE o TOKENIZE, la integración de Batch Upload está disponible. Le permite enviar una gran cantidad de transacciones al motor de pagos en un lote basado en archivos. Tenga en cuenta que Batch Upload es generalmente más lenta que la solución API, ya que las operaciones se procesan con menor prioridad y, luego, se debe cargar y analizar el archivo completo antes de que comience el procesamiento y se descarguen los resultados.
Comparación de los métodos de integración
La siguiente tabla enumera algunas de las diferencias clave entre los principales métodos de integración, para que le resulte más fácil seleccionar el método que cumpla con sus requisitos comerciales específicos.
| Característica | 3-Party Checkout | Hosted Session | 2-Party merchant hosted |
|---|---|---|---|
| Alcance PCI objetivo | Cumple con SAQ-A | Cumple con SAQ-A | Cumple con SAQ-D |
| Uso de API |
|
API del servidor REST | |
| Esfuerzo de desarrollo |
|
|
|
| Personalización de la página de pago |
|
|
Control total de la interfaz de usuario, el flujo y la experiencia del usuario. |
Cumplimiento de PCI
PCI es un conjunto de estándares de seguridad diseñados para salvaguardar los datos confidenciales de las tarjetas de pago. Los negocios que manejan pagos con tarjeta utilizan un Cuestionario de autoevaluación (SAQ) para evaluar su cumplimiento de los estándares PCI:
- SAQ-A es el SAQ más simple y básico. Significa que el negocio ha subcontratado todo el procesamiento de datos del titular de la tarjeta a un proveedor de servicios externo que cumple con el estándar de seguridad de datos (DSS) PCI, en este caso MCB Payment Gateway. Los negocios que cumplen con SAQ-A no pueden almacenar, procesar ni transmitir ningún dato del titular de la tarjeta. Pueden manejar pagos de comercio electrónico y pedidos por correo o teléfono (MOTO). Si cumple con SAQ-A, debe seleccionar el método de integración 3-Party Checkout o Hosted Session.
- SAQ-D es un SAQ más completo, diseñado para empresas más grandes y complejas que necesitan manejar diversos tipos de pagos. Los negocios que cumplen con SAQ-D pueden almacenar, procesar y transmitir datos de los titulares de tarjetas, y deben tomar las medidas de seguridad necesarias para proteger los datos de los titulares de tarjetas que se les confían. Si cumple con SAQ-D, puede utilizar el método de integración de 2-Party merchant hosted.
El motor de pagos no exige el cumplimiento de PCI específico. Su proveedor de servicios de pago (PSP) y sus adquirentes determinan qué tipo de cumplimiento esperan de usted, y el motor de pagos simplemente proporciona diferentes métodos de integración para ayudarlo a cumplir esas expectativas. El soporte para el cumplimiento de SAQ-A y SAQ-D está disponible tanto para integraciones de API como para gestión de transacciones a través de la UI de Merchant Administration.
Si necesita cumplir con SAQ-A, su PSP debe habilitarlo en la configuración de su negocio (ya sea para la API, la UI o ambas):
- Si se ha habilitado el cumplimiento de SAQ-A para la UI, el motor de pagos deshabilita las pantallas de ingreso de pedidos, lo que le impide crear pedidos MOTO (por correo/teléfono) ingresando los detalles de la tarjeta.
Your payment service provider también puede configurarlo para que cumpla con SAQ-A en la interfaz de usuario, al tiempo que le brinda la opción de romper ese cumplimiento para algún propósito específico. En ese caso, puede habilitar el privilegio Ver identificadores de cuentas sin enmascarar para cualquiera de los operadores que haya creado en el Merchant Administration. Sin embargo, habilitar ese privilegio para un operador rompe su cumplimiento de SAQ-A.
- Si se ha habilitado el cumplimiento de SAQ-A para la API, el motor de pagos rechaza las transacciones que incluyan directamente datos PCI confidenciales del titular de la tarjeta, como el número de la tarjeta. En su lugar, debe incluir un contenedor para los datos del titular de la tarjeta, como una sesión de pago o un token. El motor de pagos también enmascara cualquier número de cuenta principal (PAN) en la respuesta de la transacción. Si está utilizando la integración de Batch Upload, se rechazarán todos los lotes que contengan PAN sin enmascarar. Si solicita que se devuelvan PAN sin enmascarar en la respuesta, el motor de pagos devuelve un error para exigir el cumplimiento de SAQ-A.
Si necesita poder ver PAN sin enmascarar, comuníquese con su PSP para analizar sus opciones.