Guia Implementacion DW v2-9-2

GUÍA DE
IMPLEMENTACIÓN
DATAWEB (BOTÓN DE PAGOS)
ANDRÉS FLORES / MARIO TORRES
2020
Fecha Versión Descripción Autor
2017-10-06 1.0 Documento inicial Andrés Flores
Mario Torres
2017-11-16 2.0 Anulaciones y Diferidos Andrés Flores
2017-11-23 2.1 Intereses y meses de gracia Andrés Flores
2018-01-23 2.2 Campos adicionales en las Andrés Flores
transacciones de compras y
anulaciones en las opciones
avanzadas
2018-02-27 2.3 Campos adicionales en las Andrés Flores
transacciones de compras para
control de riesgos
2018-04-24 2.4 Campo adicional para control de Andrés Flores
riesgos
2018-08-08 2.5 Actualización y mejoras en el Andrés Flores
contenido del documento
2019-02-14 2.5.3 Se agregó código de error de Andrés Flores
reglas antifraude
2019-03-22 2.5.4 Validación campo cardholder vacío Andrés Flores
2019-05-09 2.5.5 Requisito técnico actualizado Andrés Flores
2019-05-13 2.6 Modulo Oneclickcheckout Andrés Flores
2019-06-25 2.7 Se incluye más detalle en el Andrés Flores
proceso de integración, además de
un estimado de tiempo de
desarrollo de acuerdo a las etapas
2019-08-19 2.8 Se incluye el módulo de Ruth Medina /
verificador de transacción Andrés Flores
30-09-19 2.8.1 Recomendaciones en uso de Andrés Flores
diferidos
14-10-19 2.9 Nuevo método de autenticación Andrés Flores
28-10-19 2.9.1 Se agrega documentación sobre la Andrés Flores /
eliminación de token Ruth Medina
30-11-19 2.9.2 Mejoras en la autenticación del Andrés Flores /
canal del botón de pagos. Uso de Ruth Medina
autorizador y eliminación de
parámetros.
1. Introducción .......................................................................................................................... 7
2. DATAWEB (COPYandPAY)...................................................................................................... 7
2.1 Componentes ...................................................................................................................... 7
2.2 Tecnologías.......................................................................................................................... 7
2.3 Certificados.......................................................................................................................... 7
2.4 Sobre los ejemplos .............................................................................................................. 8
2.5 Sobre los Plugins ................................................................................................................. 8
2.6 Sobre las transacciones y monto......................................................................................... 8
2.7 Esquema de Seguridad ........................................................................................................ 8
3. Fases de Integración.............................................................................................................. 8
3.1 Fase Prueba Inicial ......................................................................................................... 8
3.1.1 Identificador de Pago (Checkout id) ...................................................................... 9
3.1.2 Formulario de Pago ............................................................................................. 10
3.1.3 Procesamiento de la compra............................................................................... 12
3.2 Fase Prueba Final ........................................................................................................ 13
3.2.1 Nuevos campos, identificador de Pago (Checkout id) ............................................... 13
3.2.1.1 Nombre ............................................................................................................... 13
3.2.1.2 Segundo Nombre ................................................................................................ 14
3.2.1.3 Apellido ............................................................................................................... 14
3.2.1.4 Dirección IP.......................................................................................................... 14
3.2.1.5 Identificador del Cliente en el Comercio ............................................................. 14
3.2.1.6 Número de Transacción ...................................................................................... 14
3.2.1.7 Dirección de Correo Electrónico.......................................................................... 14
3.2.1.8 Tipo de Documento de Identificación del Usuario .............................................. 14
3.2.1.9 Documento de Identificación del Usuario........................................................... 15
3.2.1.10 Datos del producto ............................................................................................ 15
3.2.1.10.1 Nombre ...................................................................................................... 15
3.2.1.10.2 Descripción ................................................................................................. 15
3.2.1.10.3 Precio.......................................................................................................... 15
3.2.1.10.4 Cantidad ..................................................................................................... 15
3.2.1.11. Teléfono del cliente .......................................................................................... 15
3.2.1.12 Dirección de entrega ......................................................................................... 15
3.2.1.13 Dirección del Cliente ......................................................................................... 16
3.2.1.14 País de entrega .................................................................................................. 16
3.2.1.15 País del Cliente .................................................................................................. 16
3.2.1.16 Modo de Prueba................................................................................................ 16
3.2.1.17 Parámetros Personalizados ............................................................................... 16
3.2.1.17.1 Custom Parameters .................................................................................... 19
3.2.1.18 Risk Parameters ................................................................................................ 19
4. Código de Mensajes. ........................................................................................................... 22
5. Anulaciones ......................................................................................................................... 24
5.1 Campos obtenidos de la respuesta ............................................................................. 25
5.2 Campos obtenidos del usuario (Cliente) ..................................................................... 26
5.3 Función de eliminación ............................................................................................... 27
6. Opciones Avanzadas............................................................................................................ 28
6.1 Diferidos ...................................................................................................................... 28
6.2 Intereses ...................................................................................................................... 31
6.3 Meses de gracia ........................................................................................................... 31
6.4 Formulario de Opciones Avanzadas ............................................................................ 32
6.4.1 Anulaciones en Opciones Avanzadas .................................................................. 34
6.5 Validación campos vacíos.................................................................................................. 35
7. OneclickCheckout (Pago con un click) ................................................................................. 35
7.1 Preparación del pago (primera compra) ..................................................................... 35
7.2 Eliminación del Token ................................................................................................. 37
8. Otros métodos de integración ............................................................................................ 37
9. Personalización.................................................................................................................... 38
10. Verificador de transacciones ........................................................................................... 38
10.2 Verificar por identificador de la transacción ................................................................... 38
10.2 Verificar por el número de transacción del comercio ................................................. 40
11. Paso a Producción (Cronograma estimado) .................................................................... 40
ANEXOS ....................................................................................................................................... 43
Anexo A.1 Php ......................................................................................................................... 43
Anexo A.2 ................................................................................................................................ 44
Anexo B.1 Java......................................................................................................................... 45
Anexo B.2 ................................................................................................................................ 46
Anexo C.1 C# ........................................................................................................................... 47
Anexo C.2 ................................................................................................................................ 48
Anexo D.1 Python .................................................................................................................... 49
Anexo D.2 ................................................................................................................................ 50
FIGURA 1. FUNCIÓN REQUEST (TOKEN CHECKOUTID) 10

FIGURA 2. RESPUESTA FORMATO JSON 10
FIGURA 3. ESQUEMA DE PETICIÓN DEL TOKEN 10
FIGURA 4. SCRIPT DE FORMULARIO DE PAGO. 10
FIGURA 5. CÓDIGO HTML DEL FORMULARIO DE PAGO 11
FIGURA 6. CÓDIGO EJEMPLO DEL FORMULARIO DE PAGO 11
FIGURA 7. FORMULARIO DE PAGO CON DATOS DE PRUEBAS PARA SU USO 11
FIGURA 8. FUNCIÓN REQUEST UTILIZANDO EL CHECKOUTID 12
FIGURA 9. PROCESAMIENTO DE LA TRANSACCIÓN – RESPUESTA FORMATO JSON 13
FIGURA 10 A. CÓDIGO EJEMPLO DE LA FUNCIÓN REQUEST QUE HACE LA PETICIÓN DEL CHECKOUTID 20
FIGURA 11A. RESPUESTA FORMATO JSON. INFORMACIÓN QUE RECIBE EL COMERCIO 24
FIGURA 12. FORMULARIO DE ANULACIÓN DE TRANSACCIÓN 26
FIGURA 13. CÓDIGO DE PROGRAMACIÓN DE PHP DE LA FUNCIÓN DE ANULACIÓN 27
FIGURA 14. JAVASCRIPT PARA DIFERIDOS (INSTALLMENTS). 28
FIGURA 15. CAMPO DE DIFERIDOS EN RESPUESTA DE LA TRANSACCIÓN 30
FIGURA 16. OPCIÓN DE DIFERIDOS 30
FIGURA 17. OPCIÓN INTERESES EN LOS DIFERIDOS 31
FIGURA 18. RESPUESTA JSON DE LA OPCIÓN DE INTERESES, EN ESTE CASO NO APLICA 31
FIGURA 19. OPCIÓN MESES DE GRACIA EN LOS DIFERIDOS 31
FIGURA 20. RESPUESTA JSON DE LA OPCIÓN MESES DE GRACIA, EN ESTE CASO NO APLICA 32
FIGURA 21. FORMULARIO CON LAS OPCIONES AVANZADAS AGREGADAS, EN ESTE CASO LA
COMBINACIÓN QUE SE OBSERVA SE COMPORTA COMO UNA TRANSACCIÓN CORRIENTE YA QUE
NO SE HA ELEGIDO NINGUNA OPCIÓN 32
FIGURA 22. RESPUESTA JSON CON LOS CAMPOS DE OPCIONES AVANZADAS 33
FIGURA 23. CÓDIGO JAVASCRIPT DE LAS OPCIONES AVANZADAS 34
FIGURA 24. FUNCIÓN DE ANULACIÓN EN PHP DE LAS OPCIONES AVANZADAS DONDE SE INCLUYEN LOS
CAMPOS 34
FIGURA 25. CÓDIGO PARA VALIDACIÓN DEL CAMPO CARDHOLDER (NOMBRE DEL DUEÑO DE LA
TARJETA). 35
FIGURA 26. CÓDIGO PARA ACTIVAR LA CAPTURA (TOKENIZACIÓN) DE LOS DATOS DE LA TARJETA DEL
CLIENTE. 35
FIGURA 27. FORMULARIO INCLUYENDO LA OPCIÓN DE CAPTURA DE DATOS. 36
FIGURA 28. FORMULARIO DE PAGO ONECLICKCHECKOUT (PAGO CON UN CLICK) 36
FIGURA 29. FUNCIÓN DE ELIMINACIÓN DEL TOKEN. 37
FIGURA 30. JSON DE RESPUESTA AL EJECUTAR LA FUNCIÓN DE ELIMINACIÓN. 37
FIGURA 31. MENSAJE DE ERROR EN LA TRANSACCIÓN YA QUE NO EXISTE EL TOKEN. 37
FIGURA 32. IMAGEN DE REFERENCIA EN LA PERSONALIZACIÓN DE REGLAS DE ESTILOS. 38
FIGURA 33. FUNCIÓN PARA VERIFICAR Y OBTENER SI UNA TRANSACCIÓN FUE PROCESADA
(ACEPTADA/RECHAZADA) 39
FIGURA 34. MUESTRA PARCIAL DEL JSON DE RESPUESTA DONDE ENCONTRARÁN DATOS IMPORTANTES
39
FIGURA 35. EJEMPLO DE FUNCIONAMIENTO EN UN PORTAL WEB 39
FIGURA 36. FUNCIÓN PARA VERIFICAR Y OBTENER SI UNA TRANSACCIÓN FUE PROCESADA
(ACEPTADA/RECHAZADA) MEDIANTE EL MERCHANTTRANSACTIONID 40
TABLA 1. PARÁMETRO VALOR IVA 12% ...................................................................................................... 17
TABLA 2. PARÁMETRO BASE TARIFA 0% .................................................................................................... 17
TABLA 3. IDENTIFICADOR DE COMERCIO ELECTRÓNICO............................................................................ 17
TABLA 4. IDENTIFICADOR PROVEEDOR DE SERVICIO ................................................................................. 18
TABLA 5. TOTAL BASE TARIFA 12% ............................................................................................................. 18
TABLA 6. LONGITUD TOTAL DEL PARÁMETRO ........................................................................................... 18
TABLA 7. CÓDIGOS DE MENSAJES .............................................................................................................. 22
TABLA 8. DETALLE DE CAMPOS EN LA FUNCIÓN DE ANULACIÓN DE UNA TRANSACCIÓN. ....................... 28
TABLA 9. PASOS PARA LA SALIDA A PRODUCCIÓN ..................................................................................... 41
1. Introducción
Dataweb les permite integrar su negocio al e-commerce mediante la implementación de un
botón de pagos en su sitio web. Con este producto, podrá ofrecerles a sus clientes la mejor
experiencia al momento de realizar sus pagos en compras en línea con todas las tarjetas
bancarias.
Todo lo expuesto en el documento es lo que se debe integrar en sus portales web, los campos
son mandatorios y el código fuente adjunto es referencial y sirve como guía, si existe algún
problema con la obtención de un dato tienen que comunicarlo vía correo electrónico a
aflores@datafast.com.ec
2. DATAWEB (COPYandPAY)
Es una solución de forma de pago que la hace segura y sencilla de integrar en los diferentes
portales e-commerce debido a su fácil integración, de aquí en adelante se lo describirá como
botón de pagos.
2.1 Componentes
Al ser una solución web, su estructura está definida por las tecnologías:
➢ HTML
➢ CSS
➢ JavaScript
Para el intercambio de datos se utiliza el formato JSON
2.2 Tecnologías
El widget por ser un componente que va con la vanguardia tecnológica es adaptable a
los lenguajes de programación modernos tales como:
➢ Python
➢ Java
➢ Php
➢ Groovy
➢ VB.Net
➢ Ruby
➢ Node Js
➢ C#
➢ Scala
2.3 Certificados
El botón de pagos utiliza certificado TLS 1.2 con encriptación SHA-2 (256 bits) por lo
que su sitio web debe poseer el mismo tanto en ambientes de pruebas y producción.
Cualquier otro certificado inferior al mencionado en el párrafo anterior debe ser

deshabilitado (TLS 1.1, SSL2, SSL3, etc.).
2.4 Sobre los ejemplos
En este documento encontrarán ejemplos de código basado en el lenguaje PHP pero
esto no indica que es la manera de hacerlo ya que cada desarrollador debe aplicar los
estándares y tecnología de plataforma a implementar el botón de pagos.
Los campos que se describen en esta guía son obligatorios.
2.5 Sobre los Plugins

No son aplicables es decir Datafast no desarrolla plugins para plataformas, lo que hace
es ofrecerles el “engine” del botón de pagos para que pueda ser adaptado a su portal.
2.6 Sobre las transacciones y monto

Cuando se está en la fase de prueba final el monto de las transacciones no debe
superar los $50 caso contrario se consumirá el cupo rápidamente de las tarjetas de
prueba. Cuando se realice el paso a producción, el comercio deberá tener a la mano
una tarjeta de crédito real y un set de datos ficticios.
2.7 Esquema de Seguridad

Cada transacción pasa por un proceso de validación y verificación antes de ser
procesada, el siguiente esquema muestra el flujo de este. Al salir la transacción del
portal pasa por dos sistemas de validaciones para finalmente llegar a los servidores de
Datafast.
3. Fases de Integración
Para la integración de la solución se ha dividido en dos etapas de pruebas antes del
paso al ambiente de producción.
3.1 Fase Prueba Inicial

En esta fase el comercio o establecimiento a implementar el botón
podrá tener una primera experiencia al interactuar con el Gateway de pagos,
Se debe tener parametrizado los campos que varían cuando se cambien de
ambientes, es decir entre staging (prueba) y producción, estos campos son:
$url, donde indica el ambiente en el cual se está trabajando (Staging / Production)

$mid, indica el identificador del comercio
$tid, indica el identificador del terminal
$textMode, donde esta variable en ambiente de producción no se incluye en la
función, pero en Staging si es necesaria (Fase final de pruebas) tal como se verá en
los ejemplos.
authentication.entityId, identificador de entidad
Authorization Bearer, parámetro de cabecera para autenticación
En la versión anterior eran mandatorios los parámetros userId y password, estos

fueron reemplazados por el Authorization Bearer.
3.1.1 Identificador de Pago (Checkout id)

En esta primera instancia se envían los parámetros básicos hacia la
plataforma de pago, para esta guía se utilizará el lenguaje PHP (Anexo
A.1). La plataforma de pago envía un token que es el denominado
checkoutId para continuar con la transacción. Si usted utiliza otro lenguaje
de por ejemplo Java puede obtener el código en el Anexo B.1, para C# el
Anexo C.1, para otros lenguajes nosotros tenemos que proporcionarles los
códigos.
Los parámetros básicos en esta sección son:
➢ entityId (8a829418533cf31d01533d06f2ee06fa)
➢ amount (Monto total obtenido de la transacción) respetando los
dos dígitos para decimales.
➢ currency (El valor es USD)
➢ paymentType (Para transacciones de compras va DB)
➢ Authorization:Bearer (
OGE4Mjk0MTg1MzNjZjMxZDAxNTMzZDA2ZmQwNDA3NDh8WHQ
3RjIyUUVOWA== )
Finalmente, la función quedará así:

Figura 1. Función Request (Token CheckoutID)
Se ejecuta la función y se obtiene la respuesta en formato JSON
Figura 2. Respuesta formato JSON
El checkoutId lo encuentra en el campo id del Json obtenido
Figura 3. Esquema de petición del Token
3.1.2 Formulario de Pago

Para la generación del formulario de pago se debe utilizar el checkoutId
obtenido en el paso anterior y de esta manera completar el código del
script que se muestra a continuación.
Figura 4. Script de Formulario de Pago.

Una vez agregado el script se procede a invocar el formulario de pago
insertando lo siguiente, donde shopperResultURL es la dirección a donde
se redirigirá la página una vez que haya llegado el mensaje de respuesta de
la plataforma de pago, por otro lado, en la clase data-brands se puede
asignar las marcas de las tarjetas que se utilizaran, siendo estas VISA
MASTER AMEX DINERS DISCOVER.
Figura 5. Código HTML del Formulario de Pago
A continuación, un ejemplo utilizando el lenguaje Php.
Figura 6. Código ejemplo del Formulario de Pago
Luego que es enviado y receptado el token (CheckoutID), el formulario está

listo para ser utilizado en el flujo de la compra.
Figura 7. Formulario de Pago con datos de pruebas para su uso
Una vez presionado el botón pagar, los datos vuelven a viajar a la

plataforma la misma que responde en formato json hacia la página
seleccionada en el parámetro shopperResultURL.
En esta página usted podrá obtener el parámetro resourcePath cuyo

contenido es: /v1/checkouts/{id}/payment y esto debe ser concatenado a
la URL https://test.oppwa.com
Con esto puede continuar con el paso 3 (Procesamiento de la compra)
3.1.3 Procesamiento de la compra

Una vez obtenido el parámetro resourcePath se procede a crear la función
siguiente y su respectiva ejecución (Anexo A.2 / B.2 / C.2), tal como lo muestra
la figura 8.
Figura 8. Función Request utilizando el CheckoutId
Finalmente, la función request envía la información respectiva a la plataforma

de pago la cual la procesa y valida el token, luego la plataforma envía la
respuesta en formato de texto JSON hacia el cliente.
Figura 9. Procesamiento de la transacción – Respuesta formato JSON
3.2 Fase Prueba Final

Una vez integrado el botón en su fase inicial de pruebas procederemos a realizar
algunos cambios en la función para poder así realizar transacciones de pruebas
hacia el switch transaccional de Datafast en ambiente de desarrollo. En la fase
inicial las transacciones no llegan hacia Datafast.
Los parámetros de autenticación en esta fase son proporcionados por Datafast:
➢ authentication.entityId
➢ Authorization:Bearer
3.2.1 Nuevos campos, identificador de Pago (Checkout id)

Se procederá describir campo por campo lo que se necesita agregar como
parámetro en la función request(). Estos campos son obligatorios y no se
puede poner valores por defecto como “SN”, “NA”, “0999999999”, etc. Si
tiene problemas para obtener desde su sistema algún campo por favor
indicarlo mediante correo electrónico.
3.2.1.1 Nombre
Este campo se refiere al nombre del usuario que está
realizando la transacción, el mismo será asignado a un campo
disponible de la plataforma.
customer.givenName | AlfNum {3,48}

3.2.1.2 Segundo Nombre
Este campo se refiere al segundo nombre del usuario que está
customer.middleName | AlfNum {2,50}
3.2.1.3 Apellido
Este campo se refiere al apellido del usuario que está
customer.surname | AlfNum {3,48}
3.2.1.4 Dirección IP
Este campo se refiere a la dirección ip del equipo desde donde
el usuario está realizando la transacción, el mismo será
asignado a un campo disponible de la plataforma.
customer.ip | AlfNum 255{1,255}
3.2.1.5 Identificador del Cliente en el Comercio

Este campo se refiere a la identificación (id único) del usuario
registrado en el sistema, el mismo será asignado a un campo
customer.merchantCustomerId | AlfNum 255{1,255}
3.2.1.6 Número de Transacción

Este campo se refiere a la identificación (id único) de la
transacción (trx) registrada en el sistema, el mismo será
asignado a un campo disponible de la plataforma.
merchantTransactionId | AlfNum 255{8,255}
3.2.1.7 Dirección de Correo Electrónico

Este campo se refiere a la dirección de correo electrónico
asociada a un usuario del sistema, el mismo será asignado a un
campo disponible de la plataforma.
customer.email | AlfNum 128{6,128}
3.2.1.8 Tipo de Documento de Identificación del Usuario

Este campo se refiere al tipo de documento de identidad del
usuario en sistema (DNI, Cédula, pasaporte, etc.), el mismo
será asignado a un campo disponible de la plataforma.
customer.identificationDocType en este caso el valor siempre

será IDCARD
3.2.1.9 Documento de Identificación del Usuario
Este campo se refiere al documento de identidad del usuario
en sistema (DNI, Cédula, pasaporte, etc.), el mismo será
asignado a un campo disponible de la plataforma. La longitud
del campo es siempre de 10 caracteres y debe coexistir con el
anterior campo caso contrario le emitirá error. En el caso de
usar RUC se debe cortar y solo enviar la longitud indicada,
internamente en su sistema puede guardar el dato completo.
customer.identificationDocId | AlfNum 10{1,10}
3.2.1.10 Datos del producto

En esta sección se describirá los campos necesarios para
almacenar la información de los ítems involucrados en la
compra, cabe aclarar que los parámetros a utilizar estarán
involucrados en arreglos de datos simples.
3.2.1.10.1 Nombre
Nombre del producto, no se acepta el &
cart.items[0].name | AlfNum 255{1,255}
3.2.1.10.2 Descripción
Descripción del producto.
cart.items[0].description | AlfNum 255{1,255}
3.2.1.10.3 Precio
Precio del producto
cart.items[0].price | Num 13 {1,10}.{2}
3.2.1.10.4 Cantidad
Cantidad del producto
cart.items[0]. quantity | Num 5 {1,12}.{0,3}
3.2.1.11. Teléfono del cliente

Número de teléfono, de formato alfanumérico y longitud
máxima de 25 caracteres.
customer.phone | AlfNum 25 {7,25}
3.2.1.12 Dirección de entrega

Dirección de entrega de la compra del cliente, de formato
alfanumérico y longitud máxima de 100 caracteres.
shipping.street1 | AlfNum 100 {1,100}

3.2.1.13 Dirección del Cliente
Dirección del cliente que realice la compra (generalmente el de
la factura), de formato alfanumérico y longitud máxima de 100
caracteres.z
billing.street1 | AlfNum 100{1,100}
3.2.1.14 País de entrega

País de entrega de compra que realiza el cliente, de formato
alfabético y longitud de 2 caracteres en mayúscula. Ejm (EC,
CL, US, etc. Formato ISO 3166-1)
shipping.country | Alf 2{2}
3.2.1.15 País del Cliente

País de compra que realiza el cliente (generalmente de la
factura), de formato alfabético y longitud de 2 caracteres en
mayúscula. Ejm (EC, CL,US, etc. Formato ISO 3166-1)
billing.country | Alf 2{2}
3.2.1.16 Modo de Prueba

Le indica a la plataforma en qué modo se están haciendo las
transacciones.
testMode
Toma dos valores, EXTERNAL. En producción este parámetro

tiene que ser eliminado completamente.
3.2.1.17 Parámetros Personalizados

Este campo tiene un tratamiento distinto a los demás ya que
dependen de muchos factores para crearlo.
Antes de definir este campo se debe tener presente la

necesidad de manipular cierta información en el proceso de
compra por parte del usuario dentro del portal, en este caso
nos referimos a la siguiente información:
• Total Base con tarifa 0%

• Total Base con tarifa 12%
• IVA 12%
• Total
Por ejemplo: Una compra con un total de $3.12 que se

desglosa de la siguiente manera:
a. Base con tarifa 12% $1
b. IVA 12% $0.12
c. Total (a+b) $1.12
d. Base con tarifa 0% $2
Total (c+d) $1.12 + $2 = $3.12 (Monto)
Ahora vamos a darles identificación, longitud y valor a cada

uno de estos datos.
Tabla 1. Parámetro valor IVA 12%
004 Código Identificador del Campo

012 Longitud del Campo: (12 caracteres)
000000000012 Valor del Campo: En este ejemplo el
valor del IVA → $0.12.
Otro ej: 000000000120 → 1,20
Finalmente tendríamos en una sola cadena lo siguiente:

004012000000000012
Tabla 2. Parámetro base tarifa 0%

012 Longitud del Campo: (12 caracteres)
000000000200 Valor del Campo: En este ejemplo el
valor de la base con tarifa 0% es $2.00

052012000000000200
Ahora solo como demostración pondremos las dos cadenas en

una sola, el orden es indiferente igual el sistema valida
internamente.
004012000000000012052012000000000200
052012000000000200004012000000000012
Tabla 3. Identificador de Comercio Electrónico

007 Longitud del Campo (7 caracteres)
0103910 Valor del Campo: 0103910

0030070103910
Tabla 4. Identificador Proveedor de Servicio

17913101 Valor del Campo: 17913101

05100817913101
Tabla 5. Total Base Tarifa 12%

000000000100 Valor del Campo: $1.00

053012000000000100
Tabla 6. Longitud Total del Parámetro
N/A Código Identificador del Campo

N/A Longitud del Campo: 4 caracteres
0081 Valor del Campo: 81 caracteres en total
Finalmente tendríamos la longitud final de toda la cadena,

cabe recalcar que se omiten los 4 caracteres de esta longitud,
es decir no se toma en cuenta 0081 para el conteo final y
siempre será el primer dato informativo de la cadena:
0081
Ejemplo final:
00810030070103910004012000000000012051008179131010
52012000000000200053012000000000100
3.2.1.17.1 Custom Parameters
Finalmente el parámetro que se requiere es el
denominado customParameters el cual necesita
como clave dos valores concatenados, esto son el
identificador del comercio (MID=1000000505) y el
identificador del terminal (TID= PD100406),
quedando finalmente construido el parámetro de la
siguiente manera:
customParameters[1000000505_PD100406]
Cabe aclara que tanto el MID y TID deben ser

solicitados a Datafast S.A.
El valor del customParameters es la cadena que se

construyó en el apartado anterior.
Luego tendremos.
customParameters[1000000505_PD100406]=
00810030070103910004012000000000012051
00817913101052012000000000200053012000
000000100
3.2.1.18 Risk Parameters

Este campo sirve para identificar al comercio en la transacción,
solo se debe poner el nombre del mismo, también es
obligatorio.
risk.parameters[USER_DATA2]
Ejemplo: “&risk.parameters[USER_DATA2]=MiComercio”
A continuación, un ejemplo de implementación en el

lenguaje PHP.
Figura 10 a. Código ejemplo de la función request que hace la petición del CheckoutID
Figura 10 b. Parte de la respuesta en formato JSON en esta segunda fase
Campo Descripción
paymentType DB
amount El mismo monto de la transacción
aprobada
currency USD
autorization Campo código de autorización. Ejm:
000093.
Este dato se lo obtiene del campo del
JSON [AuthCode]
Mes de expiración Mes de expiración de la T.C. ingresado
por el formulario [expiryMonth]
Año de expiración Año de expiración de la T.C. ingresado
por el formulario [expiryYear]
Número de referencia Este dato se lo obtiene del campo del
JSON [ReferenceNbr].
Ej.: 170926_000071
Donde el 000071 es el número de
referencia y el otro componente
170926 en el número de lote
custom_parameter MID_TID
custom_value Valor inicial del customParameters
4. Código de Mensajes.
El listado a continuación muestra los códigos de respuestas emitidos por el switch
transaccional. La descripción de los códigos debe ser personalizados para una mejor
comprensión por parte del cliente, es decir usted puede cambiar la descripción que le
llega como respuesta en el JSON para mostrarlo de mejor manera al usuario. De
manera general los códigos que empiezan por 800 son debido a un rechazo por la
entidad bancaria.
Tabla 7. Códigos de Mensajes
Código Descripción Web Detalle

000.000.000 Transaction succeeded Approved (Producción)
000.100.112 Request successfully processed in Approved (Pruebas)
000.100.110 'Merchant in Connector (Integrator)
Test Mode'
600.200.201 Channel/Merchant not configured for Invalid Merchant
this payment method
800.100.171 invalid Request Message. The request Decline Transaction o Mensaje
contains structural errors invalido
200.100.101 invalid Request Message. No valid Este mensaje refiere cuando el
XML. XML must be url-encoded! banco encontró un problema con
maybe it contains a not encoded la tarjeta del cliente por lo que es
ampersand or something similar. rechazada. El cliente debe llamar al
banco y consultar.
200.100.103 Invalid Request Message. The request Decline Transaction o Mensaje
contains structural errors invalido. Cuando hay algún dato
errado enviado
800.100.171 Transaction declined (pick up card) Pick up: Retenga y llame
700.300.700 referenced tx can not be reversed Reverso declinado
(reversal not possible anymore)
800.100.100 transaction declined for unknown Invalid Transaction. Este mensaje
reason indica que la transacción fue
rechazada por el banco pero no
indica el motivo, el cliente debe
llamar al banco y consultar.
800.100.174 transaction declined (invalid amount) Invalid Amount
800.100.151 transaction declined (invalid card) Invalid Card Number
800.100.402 cc/bank account holder not valid No such issuer. Omisión de nombre
de tarjetahabiente.
800.100.190 transaction declined (invalid Transacción declinada por el
configuration data) banco. Uno de los motivos es
debido a que enviaron un tipo de
crédito (diferido) que no esta
autorizado por el banco.
800.100.197 transaction declined (registration Customer cancellation
cancelled externally)
800.100.176 transaction declined (account Try Request Again
temporarily not available. Please try
again later)
100.400.311 transaction declined (format error) Format Error
100.100.100 request contains no creditcard, bank No credit Account
account number or bank name
800.100.165 transaction declined (card lost) Lost card
800.100.159 transaction declined (stolen card) Stolen Card
800.100.155 transaction declined (amount Insufficient Funds
exceeds credit)
100.150.100 request contains no Account data and No checking account
no registration id
100.150.205 referenced registration does not No saving account
contain an account
100.100.303 Card Expired Card Expired
800.100.170 transaction declined (transaction not Transaction no permitted
permitted)
100.550.310 amount exceeds limit for the Monto excede el cupo
registered account
800.100.168 transaction declined (restricted card) Restricted Card
800.100.179 transaction declined (exceeds Exceeds wdrl frecuency limit
withdrawal count limit)
500.100.201 Channel/Merchant is disabled (no Verifique Codigo Establecimiento
processing posible)
100.100.402 cc/bank account holder not valid Cuenta inválida
600.200.100 invalid Payment Method Modalidad invalida
700.100.200 non matching reference amount Verifique interés
800.100.157 transaction declined (wrong expiry Vigencia errada
date)
800.100.501 Card holder has advised his bank to Establecimiento cancelado
stop all recurring payments for this
merchant
800.100.100 transaction declined for unknown Verifique Plazo
reason
100.380.306 no authentication data provided in Num de autorización no existe
risk management transaction
800.100.170 transaction declined (transaction not Diferido NO permitido
permitted)
800.100.171 transaction declined (pick up card) Llame Comercio Autoriz
800.100.176 transaction declined (account Reintente
temporarily not available. Please try
again later)
900.100.201 error on the external gateway (bank) Entidad offline : Issuer or switch
inoperative. Se ha perdido la
conexión hacia el banco.
900.100.300 timeout, uncertain result Timeout:System Malfunction.
Tiempo de espera superado
800.100.176 transaction declined (account Try Request Again. Transacción
temporarily not available. Please try rechazada por el banco, intente
again later) luego o llame al banco
600.200.201 Channel/Merchant not configured for Terminal inválido
this payment method
800.100.151 transaction declined (invalid card) transaction declined (invalid card).
Tarjeta inválida
100.400.147 Payment void and transaction denied La transacción infringió una regla
by ReD Shield antifraude. Estas reglas fueron
definidas por el comercio al
momento de firmar.
Para detalles de que regla se activó

deben enviar un email a Reynaldo
Ronquillo.
rronquillo@datafast.com.ec
5. Anulaciones
Cuando Datafast aprueba una transacción de compra retorna hacia el comercio la
siguiente información. Figuras 11a, 11b, 11c.
Figura 11a. Respuesta formato JSON. Información que recibe el comercio

Figura 11b. Respuesta formato JSON. Información que recibe el comercio
Figura 11c. Respuesta formato JSON. Información que recibe el comercio
5.1 Campos obtenidos de la respuesta

Para realizar una anulación se necesitan lo siguientes campos que vienen en la
respuesta de la transacción:
Mandatorios
Código de autorización [AUTHCODE]: 000093
Número de referencia: 000071 (Dato parseado)
Identificador de la transacción [ID]: 8a82944a5ebed5f8015ebefea94142b9
customParameters[1000000505_PD100406]:
008100300701039100040120000000000120510081791310105201200000000020
0053012000000000100
No mandatorios
Numero de lote: 170926 (Dato parseado)
Código de respuesta: 00 (Dato parseado)
Código del adquirente: 04MI (Dato parseado)
Estos campos deben ser almacenados en alguna tabla de su base de datos que
definan, así como otros datos que vienen en la trama de respuesta. Cabe recalcar
que por normas PCI ni el comercio ni Datafast puede almacenar datos de tarjetas
de crédito.
5.2 Campos obtenidos del usuario (Cliente)

Existen datos que deben ser ingresados por el cliente en caso de que desee anular
la transacción mediante alguna interfaz web disponible. Ustedes deciden el
procedimiento de anulación de transacciones.
Estos campos son: número de tarjeta, mes y año de expiración, en la siguiente

imagen se puede observar un ejemplo del formulario que se entrega al cliente
para que proceda a eliminar la transacción.
Figura 12. Formulario de anulación de transacción

5.3 Función de eliminación
Para el proceso de anulación se necesitan la siguiente información tal como lo
muestra la imagen.
Figura 13. Código de programación de PHP de la función de anulación

Campo Descripción
$codigo_transaccional Campo ID del JSON de respuesta. Ejm:
8a82944a5ebed5f8015ebefea94142b9
$entityId Credenciales
$proceso RF
amount El mismo monto de la transacción
aprobada
currency USD
AUTHCODE Campo código de autorización. Ejm:
000093.
Este dato se lo obtiene del campo del
JSON AuthCode
Número de tarjeta Número de tarjeta de crédito ingresada
por el formulario
Mes de expiración Mes de expiración de la T.C. ingresado
por el formulario
Año de expiración Año de expiración de la T.C. ingresado
por el formulario
$referencia Número de referencia. Ejm: 000071
Este dato se lo obtiene en la respuesta
de la transacción en el campo del JSON
ReferenceNbr. Debe ser parseado
$custom_parameter MID_TID
$custom_value Valor inicial del customParameters
Tabla 8. Detalle de campos en la función de anulación de una transacción.
6. Opciones Avanzadas
Esta sección describirá como utilizar las opciones de diferidos, intereses y meses de
gracia, para esto deben incluir la librería JQuery, por ejemplo:
<script type=”text/javascript” src="jquery-3.2.1.js"></script>
6.1 Diferidos
Para realizar diferidos se debe agregar código javascript en la misma página o sección
en donde se invoca el formulario de pago, en el ejemplo a continuación se lo agrega de
forma estática, pero se recomienda que esto sea dinámico.
Figura 14. Javascript para diferidos (Installments).

Este código se puede generar de forma dinámica si acaso se posee los tipos de
diferidos aprobados por el banco emisor en alguna tabla de la base de datos y
agregarlos en campos de texto ocultos, sino puede dejarlo fijo en el formulario, igual la
validación es que si se selecciona la opción 0 “cero” o simplemente no se envía este
campo para transacciones corrientes.
Código:
<script type="text/javascript">
var wpwlOptions = {
onReady: function() {
var numberOfInstallmentsHtml = '<div class="wpwl-label wpwl-

label-custom" style="display:inline-block">Diferidos:</div>' +
'<div class="wpwl-wrapper wpwl-wrapper-custom" style="display:inline-

block">' +
'<select name="recurring.numberOfInstallments"><option
value="0">0</option><option value="3">3'+
'</option><option value="6">6</option><option
value="9">9</option></select>' +
'</div>';
$('form.wpwl-form-card').find('.wpwl-
button').before(numberOfInstallmentsHtml);
} } </script>
Muy importante que el nombre (atributo name) del elemento HTML (select) sea
recurring.numberOfInstallments debido a que es un campo válido y reconocido por la
plataforma de pago, cualquier cambio de este nombre no se garantiza el correcto
funcionamiento.
De acuerdo con la funcionalidad o flujo de su portal web a la hora de hacer una

transacción usted puede utilizar campos de texto ocultos para los diferidos, intereses y
meses de gracia y así evitar que el usuario manipule los select y seleccione alguna
combinación no permitida por el banco y se rechace la transacción.
Al agregar este JavaScript no se ve afectada la función request, es decir no se debe

añadir ningún parámetro alguno ya que es un campo que el formulario de pago lo
envía de forma automática.
Si se decide en aplicar los diferidos de forma dinámica entonces se sugiere que en un

paso anterior a que cargue el formulario de pago se le muestre al usuario los tipos de
diferidos autorizados y después agregan los campos de manera dinámica a la porción
de código Javascript. A continuación, un ejemplo del paso previo a cargar el
formulario.
Cuando se agregan las opciones de diferidos, en la respuesta JSON se puede observar

un campo adicional en la aprobación de la transacción tal como se muestra en la
imagen.
Figura 15. Campo de diferidos en respuesta de la transacción
Quedando el formulario con la opción de diferidos de forma estática de la siguiente

manera
Figura 16. Opción de diferidos

6.2 Intereses
Para utilizar la opción de diferidos con intereses se debe definir como el
comercio procesaría esta información, como sugerencia pueden tener una
tabla en su base de datos en la que consten el número de diferido y cual aplica
o no el interés. En el siguiente ejemplo se mostrará como insertar la opción
Intereses utilizando javascript de forma estática.
Figura 17. Opción Intereses en los diferidos
El siguiente código se debe agregar en la misma sección en donde se carga el

formulario de pago.
var frecuente = '<div class="wpwl-label wpwl-label-custom" style="display:inline-

block">Intereses:</div>' +
'<div class="wpwl-wrapper wpwl-wrapper-custom" style="display:inline-

block">' +
'<select name="customParameters[SHOPPER_interes]"><option
value="0">No</option><option value="1">Si</option></select>' +
'</div>';
$('form.wpwl-form-card').find('.wpwl-button').before(frecuente);
Así como en el caso de los diferidos se debe respetar el nombre (name) del
elemento del formulario, en este caso
name="customParameters[SHOPPER_interes]" caso contrario no será
reconocido, adicional se debe respetar el valor del atributo “value” que debe
ser 1 cuando la opción elegida es SI y 0 cuando es NO
Figura 18. Respuesta Json de la opción de intereses, en este caso no aplica
6.3 Meses de gracia

Al igual que con la opción de intereses para utilizar diferidos con meses de
gracias se debe definir como el comercio procesaría esta información. En el
siguiente ejemplo se mostrará como insertar la opción Intereses utilizando
javascript de forma estática.
Figura 19. Opción meses de gracia en los diferidos

El siguiente código se debe agregar en la misma sección en donde se carga el
formulario de pago.
var gracia = '<div class="wpwl-label wpwl-label-custom" style="display:inline-block">Meses de

Gracia:</div>' +
'<div class="wpwl-wrapper wpwl-wrapper-custom" style="display:inline-block">' +
'<select name="customParameters[SHOPPER_gracia]"><option
value="0">No</option><option value="1">Si</option></select>' +
'</div>';
$('form.wpwl-form-card').find('.wpwl-button').before(gracia);
Así como en los anteriores casos se debe respetar el nombre (name) del
elemento del formulario, en este caso
name="customParameters[SHOPPER_gracia]" caso contrario no será
reconocido, adicional se debe aplicar el valor del atributo “value” que debe ser
1 cuando la opción elegida es SI y 0 cuando es NO
Figura 20. Respuesta Json de la opción meses de gracia, en este caso no aplica
6.4 Formulario de Opciones Avanzadas

Una vez agregado las opciones requeridas el formulario nos quedaría de la
siguiente manera (imagen de referencia y no obliga a desarrollarlo de esta
manera).
Figura 21. Formulario con las opciones avanzadas agregadas, en este caso la
combinación que se observa se comporta como una transacción corriente ya que no se ha
elegido ninguna opción
Cuando se realiza el pago con las opciones avanzadas obtendremos el
siguiente JSON de respuesta.
Figura 22. Respuesta Json con los campos de opciones avanzadas
Cuando el tipo de transacción no es corriente entonces se debe tener en

cuenta los siguientes aspectos, los campos SHOPPER_interes, SHOPPER_gracia
y numberOfInstallments deben incluirse aunque ustedes no lo utilicen por
completo cada campo, es decir si no viene como respuesta entonces en su
tabla ustedes deberán igual guardar estos campos con el valor de 0 “cero”,
Ejemplo: Una transacción con diferidos sin intereses y sin meses de gracias, el
JSON de respuesta solo debería devolver el campo [numberOfInstallments] y
los otros no, pero es necesario que se guarden estos otros dos campos con el
valor de cero “0” de tal manera que siempre exista una relación.
Los valores de SHOPPER_gracia y SHOPPER_interes tienen el valor de 1 cuando

aplica y 0 cuando no, siendo estos los únicos valores.
Figura 23. Código Javascript de las opciones avanzadas
6.4.1 Anulaciones en Opciones Avanzadas

Cuando se utiliza las opciones avanzadas en el widget entonces se debe
modificar el proceso de anulación incluyendo los 3 campos así no se hayan
utilizado en una transacción, tal como cite en un ejemplo en la sección anterior
Figura 24. Función de anulación en PHP de las opciones avanzadas donde se incluyen
los campos
6.5 Validación campos vacíos
Dentro del formulario del botón de pagos se pueden validar por ejemplo que el
campo cardholder no este vacío para evitar transacciones rechazadas por el
banco renombrado el método onBeforeSubmitCard.
Figura 25. Código para validación del campo cardholder (Nombre del dueño de la
tarjeta).
7. OneclickCheckout (Pago con un click)

Esta guía le permite lograr una aceleración significativa del proceso de compra
reutilizando los datos que un cliente ingresó para una transacción.
7.1 Preparación del pago (primera compra)

En este punto se repite lo de la sección 3.2, la diferencia radica en agregar código
JavaScript como se muestra a continuación.
Figura 26. Código para activar la captura (tokenización) de los datos de la tarjeta del cliente.
Figura 27. Formulario incluyendo la opción de captura de datos.
En el Json de respuesta de la transacción podrá observa un nuevo campo llamado

registrationId el cual contiene el token asociado a los datos de la tarjeta de
crédito. Este campo debe ser guardado en una tabla de su base de datos asociada
a un id del usuario del sistema, de esta manera usted podrá consultar en la
siguiente compra si ese usuario tiene tokens asociados.
En la segunda compra, de existir tokens asociados a ese cliente entonces usted los
agregará a la primera función request() usando el parámetro registrations de la
siguiente manera.
&registrations[0].id= 8ac7a49f6ab04d18016ab2067a2731b2
&registrations[1].id= 8ac7a4a06ab05883016ab2067d3841d0
Quedando el formulario de la siguiente forma.
Figura 28. Formulario de pago OneclickCheckout (Pago con un click)

7.2 Eliminación del Token
Una vez almacenado, un token se puede eliminar usando el método DELETE HTTP
usando la siguiente función.
Figura 29. Función de eliminación del token.
La respuesta al ejecutar esta función está en formato JSON en donde podrá

obtener el código correspondiente si fue eliminado correctamente.
Figura 30. JSON de respuesta al ejecutar la función de eliminación.
Si desea comprobar que el token está eliminado puede intentar realizar una
transacción con dicho token y obtendrán el siguiente mensaje.
Figura 31. Mensaje de error en la transacción ya que no existe el token.
8. Otros métodos de integración

Una manera alterna para la integración de nuestro botón de pagos es haciéndolo con
la modalidad server-to-server, pero esta opción no es la ofrecida por defecto a los
comercios debido a que esto implica la validación de algunos factores de riesgos y
certificados.
Esta modalidad debe ser validada por Datafast y las entidades financieras involucradas.
9. Personalización
El botón de pagos puede ser personalizado en su apariencia (CSS), solo basta conocer
el nombre de las clases asociadas actualmente a los elementos. Para adicional
información se debe solicitar a Datafast.
Figura 32. Imagen de referencia en la personalización de reglas de estilos.
Para validaciones que involucren JavaScript seguir la referencia del apartado 6.5
10. Verificador de transacciones

En el caso de que el portal no reciba el mensaje de aprobación o rechazo de la
transacción se ha implementado la funcionalidad de verificar si la misma consta en
nuestra base, de ser así usted podrá realizar una consulta y obtener los datos de esta e
ingresarla a su sistema. Existen dos maneras de realizar las verificaciones.
10.2 Verificar por identificador de la transacción

En esta modalidad se podrá consultar mediante el identificador de la
transacción es decir por el paymentId
Figura 33. Función para verificar y obtener si una transacción fue procesada (aceptada/rechazada)
Cuando se ejecuta la función se obtendrá una respuesta en formato JSON en

donde encontrará los datos de la transacción la cual puede ser manipulada por
el desarrollador.
Figura 34. Muestra parcial del JSON de respuesta donde encontrarán datos importantes
Figura 35. Ejemplo de funcionamiento en un portal web

10.2 Verificar por el número de transacción del comercio
En esta modalidad se puede consultar por el identificador único de la
transacción del comercio (merchantTransactionId).
Figura 36. Función para verificar y obtener si una transacción fue procesada (aceptada/rechazada) mediante el
merchantTransactionId
Al igual que la primera modalidad esta función retorna como respuesta un

JSON en el cual podrán obtener los datos de la transacción. Deben tomar en
cuenta que cambian ciertas claves (keys) dentro del array y que puede
retornar mas de un dato en el caso de que se desea consultar una transacción
y esta fue anulada, por lo que en la consulta se obtendrán dos registros, el DB y
el RF
11. Paso a Producción (Cronograma estimado)

Para salir a producción se debe tener presente el siguiente procedimiento de
certificación.
Una vez que se ha desarrollado el botón en ambiente de pruebas se realiza lo

siguiente:
Tabla 9. Pasos para la salida a producción
Proceso Descripción Tiempo Responsable

Estimado
Script de Datafast enviará un archivo con 1 día Comercio
Pruebas las instrucciones necesarias para
llenarlo con datos de las
transacciones de pruebas
Validación de Una vez que el comercio ha 1 a 2 días Datafast /
Script entregado vía correo electrónico Comercio
el archivo de las transacciones
entonces se procede a validar
que cumpla con los requisitos
establecidos en este documento.
Si existe alguna inconsistencia en
los datos se le hará conocer para
su corrección por parte del
Comercio
Escaneo de Datafast con el fin de garantizar 2 días Datafast /
Vulnerabilidades que las transacciones se realicen laborables Comercio
en un ambiente seguro procede a (Escaneo
escanear el sitio web del e
comercio en busca de informe)
vulnerabilidades. Se entrega un
informe al comercio, si hay
remediaciones por hacer
entonces será el comercio quien
estime sus tiempos de
correcciones, una vez entregada
las modificaciones se reinicia el
proceso de escaneo lo que
involucra otra vez de 24 a 48
horas para entregar el informe.
Gestión de Datafast se encargar de gestionar 4 días Datafast
códigos la creación de códigos bancarios laborables
bancarios que autoricen al comercio poder
transacciones con el botón de
pagos.
Es importante tener claro los

tipos de créditos habilitados por
la entidad financiera
Pre-Producción Se envían las instrucciones finales 1 día Datafast
para que realicen el ajuste
necesario al código fuente para
que las transacciones ahora se
direccionen al ambiente de
producción, se hace entrega de
credenciales, así como MID y TID.
Ajuste de El comercio se encargará de 1 día Comercio

códigos realizar los ajustes al código para
salir a producción, notificará a
Datafast cuando haya terminado
para la revisión respectiva
Salida a Se coordina fecha y hora para 1 día Datafast/Comercio
Producción realizar una transacción en
producción para esto el comercio
deberá tener una tarjeta de
crédito real, así como un ítem de
prueba en su sistema con un
valor no mayor a $1.00
ANEXOS
Anexo A.1 Php
Paso 1. Código básico en lenguaje PHP, función para obtener el checkoutId.
function request() {
$url = "https://test.oppwa.com/v1/checkouts";
$data = "entityId=8a829418533cf31d01533d06f2ee06fa" .
"&amount=92.00" .
"&currency=USD" .
"&paymentType=DB";
$ch = curl_init();
curl_setopt($ch, CURLOPT_URL, $url);
curl_setopt($ch, CURLOPT_HTTPHEADER, array(
'Authorization:Bearer
OGE4Mjk0MTg1MzNjZjMxZDAxNTMzZDA2ZmQwNDA3NDh8WHQ3RjIyUUVOWA=='));
curl_setopt($ch, CURLOPT_POST, 1);
curl_setopt($ch, CURLOPT_POSTFIELDS, $data);
curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, false);// this should be set to true in

production
curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
$responseData = curl_exec($ch);
if(curl_errno($ch)) {
return curl_error($ch);
curl_close($ch);
return $responseData;
}
Anexo A.2
PASO 3. Código básico en PHP, función de comprobación del estado de la transacción.
Previamente ya se ha obtenido el parámetro $resourcePath basado en la URL en el atributo
action del tag FORM
function request() {
$url = "https://oppwa.com".$resourcePath;
$url .= "?entityId=".$entityId;
$ch = curl_init();
curl_setopt($ch, CURLOPT_URL, $url);
curl_setopt($ch, CURLOPT_HTTPHEADER, array(
'Authorization:Bearer
OGE4Mjk0MTg1MzNjZjMxZDAxNTMzZDA2ZmQwNDA3NDh8WHQ3RjIyUUVOWA=='));
curl_setopt($ch, CURLOPT_CUSTOMREQUEST, 'GET');
curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, false);// this should be set to true in

production
curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
$responseData = curl_exec($ch);
if(curl_errno($ch)) {
return curl_error($ch);
curl_close($ch);
return $responseData;
}
Anexo B.1 Java
Paso 1. Código básico en lenguaje JAVA, función para obtener el checkoutId
private String request() throws IOException {
HttpsURLConnection conn = (HttpsURLConnection) url.openConnection();
conn.setRequestMethod("POST");
conn.setRequestProperty("Authorization", "Bearer
OGE4Mjk0MTg1MzNjZjMxZDAxNTMzZDA2ZmQwNDA3NDh8WHQ3RjIyUUVOWA==");
conn.setDoInput(true);
conn.setDoOutput(true);
String data = ""
+ "entityId=8a829418533cf31d01533d06f2ee06fa"
+ "&amount=92.00"
+ "&currency=USD"
+ "&paymentType=DB";
DataOutputStream wr = new DataOutputStream(conn.getOutputStream());
wr.writeBytes(data);
wr.flush();
wr.close();
int responseCode = conn.getResponseCode();
InputStream is;
if (responseCode >= 400) is = conn.getErrorStream();
else is = conn.getInputStream();
return IOUtils.toString(is);
}
Anexo B.2
PASO 3. Código básico en JAVA, función de comprobación del estado de la transacción.
Previamente ya se ha obtenido el parámetro String resourcePath basado en la URL en el
atributo action del tag FORM
private String request() throws IOException {
URL url = new URL("https://test.oppwa.com/v1/checkouts/{id}/payment

?entityId 8a829418533cf31d01533d06f2ee06fa");
HttpsURLConnection conn = (HttpsURLConnection) url.openConnection();
conn.setRequestMethod("GET");
conn.setRequestProperty("Authorization", "Bearer
OGE4Mjk0MTg1MzNjZjMxZDAxNTMzZDA2ZmQwNDA3NDh8WHQ3RjIyUUVOWA==");
int responseCode = conn.getResponseCode();
InputStream is;
if (responseCode >= 400) is = conn.getErrorStream();
else is = conn.getInputStream();
return IOUtils.toString(is);
}
Anexo C.1 C#
Paso 1. Código básico en lenguaje C#, función para obtener el checkoutId
public Dictionary<string, dynamic> Request() {
Dictionary<string, dynamic> responseData;
string data=" entityId=8a829418533cf31d01533d06f2ee06fa" +
"&amount=92.00" +
"&currency=USD" +
"&paymentType=DB";
string url = "https://test.oppwa.com/v1/checkouts";
byte[] buffer = Encoding.ASCII.GetBytes(data);
HttpWebRequest request = (HttpWebRequest)HttpWebRequest.Create(url);
request.Method = "POST";
request.Headers["Authorization"] = "Bearer
OGE4Mjk0MTg1MzNjZjMxZDAxNTMzZDA2ZmQwNDA3NDh8WHQ3RjIyUUVOWA==";
request.ContentType = "application/x-www-form-urlencoded";
Stream PostData = request.GetRequestStream();
PostData.Write(buffer, 0, buffer.Length);
PostData.Close();
using (HttpWebResponse response = (HttpWebResponse)request.GetResponse())
Stream dataStream = response.GetResponseStream();
StreamReader reader = new StreamReader(dataStream);
var s = new JavaScriptSerializer();
responseData = s.Deserialize<Dictionary<string, dynamic>>(reader.ReadToEnd());
reader.Close();
dataStream.Close();
return responseData;
}
Anexo C.2
PASO 3. Código básico en C#, función de comprobación del estado de la transacción.
public Dictionary<string, dynamic> Request() {
Dictionary<string, dynamic> responseData;
string data="entityId=8a829418533cf31d01533d06f2ee06fa";
string url = "https://test.oppwa.com/v1/checkouts/{id}/payment?" + data;
HttpWebRequest request = (HttpWebRequest)HttpWebRequest.Create(url);
request.Method = "GET";
request.Headers["Authorization"] = "Bearer
OGE4Mjk0MTg1MzNjZjMxZDAxNTMzZDA2ZmQwNDA3NDh8WHQ3RjIyUUVOWA==";
using (HttpWebResponse response = (HttpWebResponse)request.GetResponse())
Stream dataStream = response.GetResponseStream();
StreamReader reader = new StreamReader(dataStream);
var s = new JavaScriptSerializer();
responseData = s.Deserialize<Dictionary<string, dynamic>>(reader.ReadToEnd());
reader.Close();
dataStream.Close();
return responseData;
}
Anexo D.1 Python
Paso 1. Código básico en lenguaje Python, función para obtener el checkoutId
import urllib, urllib2, json
def request():
url = "https://test.oppwa.com/v1/checkouts"
data = {
'entityId' : '8a829418533cf31d01533d06f2ee06fa',
'amount' : '92.00',
'currency' : 'USD',
'paymentType' : 'DB'
try:
opener = urllib2.build_opener(urllib2.HTTPHandler)
request = urllib2.Request(url, data=urllib.urlencode(data))
request.add_header('Authorization', 'Bearer
OGE4Mjk0MTg1MzNjZjMxZDAxNTMzZDA2ZmQwNDA3NDh8WHQ3RjIyUUVOWA==')
request.get_method = lambda: 'POST'
response = opener.open(request)
return json.loads(response.read());
except urllib2.HTTPError, e:
return e.code;
Anexo D.2
PASO 3. Código básico en Python, función de comprobación del estado de la transacción.
import urllib, urllib2, json
def request():
url = "https://test.oppwa.com/v1/checkouts/{id}/payment"
url += '?entityId=8a829418533cf31d01533d06f2ee06fa'
try:
opener = urllib2.build_opener(urllib2.HTTPHandler)
request = urllib2.Request(url, data='')
request.add_header('Authorization', 'Bearer
OGE4Mjk0MTg1MzNjZjMxZDAxNTMzZDA2ZmQwNDA3NDh8WHQ3RjIyUUVOWA==')
request.get_method = lambda: 'GET'
response = opener.open(request)
return json.loads(response.read());
except urllib2.HTTPError, e:
return e.code;

Guia Implementacion DW v2-9-2

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Guia Implementacion DW v2-9-2

Cargado por

Copyright:

Formatos disponibles

GUÍA DE

FIGURA 1. FUNCIÓN REQUEST (TOKEN CHECKOUTID) 10

Para el intercambio de datos se utiliza el formato JSON

Cualquier otro certificado inferior al mencionado en el párrafo anterior debe ser

Los campos que se describen en esta guía son obligatorios.

2.5 Sobre los Plugins

2.6 Sobre las transacciones y monto

2.7 Esquema de Seguridad

3.1 Fase Prueba Inicial

$url, donde indica el ambiente en el cual se está trabajando (Staging / Production)

En la versión anterior eran mandatorios los parámetros userId y password, estos

3.1.1 Identificador de Pago (Checkout id)

Los parámetros básicos en esta sección son:

Finalmente, la función quedará así:

Se ejecuta la función y se obtiene la respuesta en formato JSON

Figura 2. Respuesta formato JSON

El checkoutId lo encuentra en el campo id del Json obtenido

Figura 3. Esquema de petición del Token

3.1.2 Formulario de Pago

Figura 4. Script de Formulario de Pago.

Figura 5. Código HTML del Formulario de Pago

A continuación, un ejemplo utilizando el lenguaje Php.

Figura 6. Código ejemplo del Formulario de Pago

Luego que es enviado y receptado el token (CheckoutID), el formulario está

Figura 7. Formulario de Pago con datos de pruebas para su uso

Una vez presionado el botón pagar, los datos vuelven a viajar a la

En esta página usted podrá obtener el parámetro resourcePath cuyo

3.1.3 Procesamiento de la compra

Figura 8. Función Request utilizando el CheckoutId

Finalmente, la función request envía la información respectiva a la plataforma

3.2 Fase Prueba Final

Los parámetros de autenticación en esta fase son proporcionados por Datafast:

3.2.1 Nuevos campos, identificador de Pago (Checkout id)

customer.givenName | AlfNum {3,48}

customer.middleName | AlfNum {2,50}

customer.surname | AlfNum {3,48}

customer.ip | AlfNum 255{1,255}

3.2.1.5 Identificador del Cliente en el Comercio

customer.merchantCustomerId | AlfNum 255{1,255}

3.2.1.6 Número de Transacción

merchantTransactionId | AlfNum 255{8,255}

3.2.1.7 Dirección de Correo Electrónico

customer.email | AlfNum 128{6,128}

3.2.1.8 Tipo de Documento de Identificación del Usuario

customer.identificationDocType en este caso el valor siempre

customer.identificationDocId | AlfNum 10{1,10}

3.2.1.10 Datos del producto

cart.items[0].name | AlfNum 255{1,255}

cart.items[0].description | AlfNum 255{1,255}

cart.items[0].price | Num 13 {1,10}.{2}

cart.items[0]. quantity | Num 5 {1,12}.{0,3}

3.2.1.11. Teléfono del cliente

customer.phone | AlfNum 25 {7,25}

3.2.1.12 Dirección de entrega

shipping.street1 | AlfNum 100 {1,100}

billing.street1 | AlfNum 100{1,100}

3.2.1.14 País de entrega

shipping.country | Alf 2{2}

3.2.1.15 País del Cliente

billing.country | Alf 2{2}

3.2.1.16 Modo de Prueba

Toma dos valores, EXTERNAL. En producción este parámetro

3.2.1.17 Parámetros Personalizados