- Pautas de integración
- Implementación de una integración de Direct Payment
- Conocer sus campos de información
Conocer sus campos de información
Antes de realizar una transacción de prueba, debe estar preparado con los valores de los campos que requieren su entrada. Independientemente del método que elija para generar estos valores, manual o generados de manera automática mediante un script, los valores adecuados para estos campos pueden simplificar el proceso de administrar pedidos y transacciones, sobre todo, recuperar transacciones perdidas. Para entender el concepto básico de los pedidos y las transacciones, consulte Pedidos y transacciones.
El motor de pagos tiene un identificador único que utiliza para identificar un pedido particular enviado por usted. Debe asignar ese identificador como parte de la primera transacción del pedido. Este identificador se denomina order.id (proporcionado como orderID en la URL para REST). Se recomienda que proporcione la clave natural del pedido (identificación del carrito de compras, número de factura) dentro de su sistema al motor de pagos. Esto facilita hacer un seguimiento entre su sistema y el motor de pagos. El motor de pagos también intenta usar el order.id en los mensajes del adquirente. De esa manera, los tres sistemas —el suyo, el motor de pagos y el banco— estarán vinculados por el identificador común. Sin embargo, esta situación ideal podría no ser factible debido a las limitaciones de los distintos sistemas.
Es posible que el identificador del pedido no sea adecuado como referencia en su sistema. Por ejemplo, si su sistema reutiliza identificadores de pedidos o agrupa varias ofertas bajo un pedido, entonces el identificador de pedido no será adecuado. En este caso, puede proporcionar un valor adicional, el order.reference, para rastrear entre su sistema y el Mastercard Gateway.
El motor de pagos debe pasar un identificador al adquirente. Intentará utilizar su identificador de pedido, posiblemente en combinación con su identificador de transacción (ver más abajo). Sin embargo, si eso no es adecuado para su adquirente, el motor de pagos los transformará en un valor adecuado. En todos los casos, el motor de pagos devuelve el identificador que se usó, en el campo transaction.acquirer.transactionId.
Sin embargo, si desea controlar el valor que el motor de pagos proporciona al adquirente, entonces puede proporcionar un valor transaction.acquirer.transactionId en la solicitud.
Referencia API de Identificador de pedido de adquirente[REST][NVP]
order.id y order.reference o transaction.acquirer.transactionId para obtener un buen control de la identidad en cada sistema.El Mastercard Gateway tiene un identificador único que usa para identificar cada transacción determinada dentro del pedido. Este identificador se denomina transaction.id (proporcionado como transactionID en la URL para REST). Normalmente no tendrá una clave natural para esto, pero si la tiene, se recomienda que la use. Si no es así, un número secuencial o aleatorio es adecuado.
Referencia de API de identificador de transacción[REST][NVP]
Para obtener información sobre los tipos de campos y las reglas de validación, consulte la Referencia de API.
Restricciones de campo en el formulario HTML
No todo campo se puede mostrar en el formulario HTML, de allí que deba tener cuidado con qué mostrar, qué calcular en el código y qué no etiquetar como campos ocultos.
Es muy importante para la seguridad de su integración exponer SOLO la cantidad mínima de datos a su pagador. Con esto en mente, solo debe representar campos de formulario que requieran información del pagador.
Es una mejor práctica de la industria (y potencialmente un requisito de seguridad) incluir solo campos de formulario que requieran la entrada del usuario. Usar campos ocultos para almacenar o pasar cualquier dato no es aceptable, ya que estos campos están expuestos al pagador y pueden ser editados por alguien con malas intenciones para posiblemente procesar transacciones fraudulentas o algo peor.
La sección anterior describió la mejor práctica de utilizar únicamente campos de formulario que requieren la entrada del usuario. Aún más importante, NUNCA debe exponer los siguientes campos a un pagador (incluido el uso de un campo oculto):
Merchant IDAPI Password
Estos valores debe almacenarlos su aplicación/sitio web de manera segura en un archivo de configuración o base de datos. Si un usuario fraudulento obtuviera acceso a estos datos, su cuenta sería susceptible a un posible ataque.