3. Realizar pago

Como último paso se puede optar por realizar el pago con el token obtenido en el momento y finalizar el proceso, y en forma opcional también guardar el token devuelto (solo para usuarios identificados, no válido para usuario anónimos) para hacer compras futuras con ese medio de pago registrado para el cliente.

• Para el caso del pago, se hará un POST a:

https://testing.plexo.com.uy:4043/SecurePaymentGateway.svc/Operation/Purchasetesting.plexo.com.uy

Firmado como todos los demás paquetes con la versión JSON del objeto PaymentRequest, que deberá contener:

• ClientReferenceId

  Referencia de la transacción para trazabilidad de vuestro lado

• CurrencyId

  Código de moneda de la compra (1-Peso, 2-Dolar)

• FinancialInclusion

  Campo para enviar información sobre la Ley de Inclusión Financiera, que contiene:

  ○ BilledAmount: monto total de la compra con impuestos

  ○ InvoiceNumbe: número de factura

  ○ TaxedAmount: monto neto de la venta que lleva impuestos

  ○ Type: tipo de Ley que aplica: 0-No aplica, 1-Ley 17934, 6-Ley 19210.

• ○ VATAmount (*Opcional): monto que corresponde a los impuestos de la venta

• Installments

  Cantidad de cuotas

• Items

  Es una lista con los ítems de la compra, que contiene los siguientes campos:

  ○ Amount : monto del item

  ○ ClientItemReferenceId : ID del item

  No se puede especificar la moneda para cada ítem, se asume que es para todos la misma que se especificó en el campo CurrencyId.

• PaymentInstrumentInput

  Contiene fundamentalmente el InstrumentToken y una lista de valores opcionales (como el CCV, si es requerido) que deben mandarse según los requerimientos del proveedor de medio de pago. Para la etapa de testing esto no es importante.

• OptionalCommerceId (*Opcional)

  Cada cliente debe configurar sus comercios por cada medio de pago (y definir uno por defecto), pero hay casos donde el comercio es una plataforma que ofrece servicios a múltiples comercios (o no definió uno por defecto). Para especificar a qué comercio se le debe adjudicar la transacción, se utiliza este campo opcional.

  IMPORTANTE: Tener en cuenta que es solo opcional si ya tienes un comercio dado de alta. Si no, antes de intentar un pago, hay que definir un comercio, hacer el alta, setearlo por defecto y luego configurarle los medios de pago. Dar alta a un comercio

• LoyaltyProgramAmount (*Opcional)

  Nuevo campo opcional para el pago con productos de afinidad, como por ejemplo Metros de OCA. En este campo se envía la cantidad de metros a utilizar como forma de pago.

• OptionalInstrumentFields (*Opcional)

  Algunos medios de pago, pueden requerir información adicional en las transacciones, como es el caso específico de VISA.

• CommerceReserveExpirationInSeconds (*Opcional) Para el caso de pagos asincrínicos, se puede modificar el tiempo de expiración por defecto (24 hrs) mediante este parámetro. Si se quiere esperar solamente que un cliente realice un pago con débito bancario en 30 minutos, entonces se debe enviar el valor 1800 (segundos).

• ThreeDSReferenceId (*Opcional) Es un parametro para enviar el ClientReferenceId que se utilizo en caso de querer validar la compra con 3DSecure (ver punto 15. Autenticación 3DSecure).

Plexo.Models/FieldType.cs at master · plexouy/Plexo.ModelsGitHub

El campo CybersourceDeviceFingerprint es mandatorio para todas las transacciones con VISA (por Totalnet) y cuya implementación se detalla más adelante.

Se obtendrá como respuesta la versión en JSON de un objeto Transaction con la información de la transacción realizada

IMPORTANTE: Hay que tener importante cuidado en el manejo de los campos de tipo “decimal” en Objetos como Item.Amount o FinancialInclusion.BilledAmount donde por motivos de deserialización JSON del lado del servidor, los valores enteros deben venir siempre con un formato “#.0” que indique un número decimal. Es decir, si pretendemos enviar un valor de 300, debe generarse como 300.0 antes de generar la firma y ser enviado (el punto como separador de decimales).

DeviceFingerprint para VISA y MasterCard (adquirencia de Totalnet u OCA)

Para estos casos se solicita la implementación de la captura del DeviceFingerprint en cada transacción obligatoriamente, información que se utiliza en los sistemas de control de fraude.

Antes de hacer una invocación a Plexo con el token del medio de pago, desde la Web o APP de e-commerce deben primero obtener el DeviceFingerprint del dispositivo del usuario final (un script en la Web, o API desde una APP).

La URL es https://h.online-metrix.net/fp/tags.js?org_id=IdEnvironment&session_id=IdComercio IdInvocacion donde:

• IdEnvironment: donde se debe utilizar 45ssiuz3 para test y 9ozphlqx para producción.

• IdComercio: en el caso de VISA es el ID del comercio para el cual se va a hacer la transacción. Si es MasterCard procesado por OCA se utiliza oca_plexo.

• IdInvocacion: es un ID que tiene que ser único por invocación. Se recomienda utilizar el mismo ID de la transacción de pago.

Agregar Script de invocación a la Web de e-commerce:

<head>
 <script type="text/javascript" 
 src="https://h.online-metrix.net/fp/tags.js?org_id=45ssiuz3&session_id=visanetuy_px_1234TRX2157"></script>
</head>

<body>
 <noscript>
 <iframe style="width: 100px; height: 100px; border: 0; position: absolute; top: -5000px;" 
 src="https://h.online-metrix.net/fp/tags?org_id=45ssiuz3&session_id=visanetuy_px_1234TRX2157"></iframe>
 </noscript>
</body>

En este ejemplo, se ejecuta este Script en el e-commerce del cliente antes de invocar a Plexo, para el comercio “visanetuy_px_1234” (oca_plexo en caso de Master vía OCA) y con un ID “TRX2157”. Luego en el momento de invocar a Plexo, se envía en el campo opcional CybersourceDeviceFingerprint el valor TRX2157.

En el caso de requerir implementar esto para una APP, se puede ver la guia de integracion aqui. Para descargar SDK de IOS haga click aqui y para Android aqui.

Pagos Recurrentes

En el caso de pagos de servicios por recurrencia, se debe enviar un parámetro más para que VISA no rechace las transacciones por antifraude al repetir el mismo DeviceFingerprint.

Para este caso se agregan dos campos opcionales:

• RecurringPayment: este campo es un nuevo FieldType que se envía dentro de OptionalInstrumentFields con el valor “true” para el “ALTA” del servicio. Se debe guardar el valor de ExtendedResponse dentro de TransactionResultText.

• Plan: luego del proceso de Alta, al siguiente movimiento de cobro se debe volver a enviar RecurringPayment = true y Plan=valor de ExtendedResponse obtenido en el Alta previa.

Entonces el procedimiento es el siguiente:

1. Para especificar que se trata de un servicio de RECURRENCIA, en el primer movimiento de ALTA del servicio donde se registra la tarjeta, se debe agregar el campo opcional FieldType.RecurringPayment = "true".

2. De la respuesta (en el Callback), se debe guardar el valor de ExtendedResponse dentro de TransactionResultText (ej: "TransactionResultText":"Operacion Aprobada - RRN: 5813575255396483804011 AuthorizationCode: 831000 ExtendedResponse: 016153570198200" para enviar en las siguientes transacciones recurrentes de esa tarjeta VISA.

3. Al ejecutar los cobros recurrentes siguientes, deben enviar adicionalmente dos campos opcionales: FieldType.RecurringPayment = "true" y FieldType.Plan = "016153570198200" donde Plan contiene el valor devuelto por ExtendedResponse en el alta del servicio.

De esta manera el procesador de VISA sabe que se trata de un servicio de Recurrencia e ignora que el DeviceFingerprint enviado sea siempre con el mismo origen.