Publicación técnica
Primeros pasos con la integración de pasarelas de pago
Poner en marcha una aplicación de pagos implica saber gestionar al menos dos tipos distintos de integración: en primer lugar, debes saber cómo integrar el hardware necesario (es decir, el lector de tarjetas y aquello a lo que se conecta); después, debes saber cómo integrarte con un «back end» de pagos, como una pasarela de pago en línea (la entidad que «autoriza» la transacción y la procesa para su liquidación).
En publicaciones anteriores, he hablado mucho de la parte de integración de hardware de este rompecabezas, que en realidad no es tan complicada, porque con los lectores de tarjetas de ID TECH puedes utilizar nuestro SDK universal para comunicarte con los dispositivos desde un entorno de lenguaje de alto nivel, o bien optar por una solución basada exclusivamente en JavaScript, si estás dispuesto a incorporar Node JS a tu arquitectura. En cualquier caso, comunicarse con los dispositivos de ID TECH no supone un gran reto.
Pero queda una pregunta pendiente: una vez que el lector de tarjetas de crédito lee el chip o la banda magnética, ¿cómo conviertes esa información en una transacción aprobada?
Es de suponer que ya sabes qué procesador de tarjetas de crédito gestionará tus solicitudes. Por tanto, el problema se reduce realmente a averiguar qué tipo de soporte de SDK ofrece tu procesador o pasarela para atender solicitudes en línea.
La mayoría de las pasarelas o procesadores cuentan con un programa para desarrolladores o un portal de desarrollo en línea, donde puedes obtener SDK para crear aplicaciones de pago. Estos SDK suelen permitir desarrollar una combinación de componentes de front-end y back-end para acceder a las API de pago del procesador. A su vez, las API de pago admiten el envío de datos de banda magnética o de datos ICC (tarjeta con chip) por la red, a un procesador back-end, con el fin de obtener autorización en tiempo real.
La autorización de pago no es más que uno de los varios tipos de solicitudes en línea que probablemente tendrás que admitir. En la siguiente tabla se muestran algunos de los demás tipos de solicitud.
Tipo de solicitud
Descripción
Autorización
Solicitar autorización de pago
Configuración
Confirmar una solicitud de autorización previa
Sin conexión
Liquidar una transacción EMV fuera de línea
Preautorización
Confirmar que los datos de la tarjeta son válidos mediante un importe pequeño de transacción
Reembolso
Reembolsar una transacción previamente liquidada
Prueba
Probar la conectividad con el procesador
Notificación de remisión por voz
Notificar al procesador el resultado de una solicitud de referencia por voz
Anulación
Se utiliza para anular una transacción que aún no se ha liquidado
Si revisas la documentación del SDK de tu procesador de pagos, verás que hay bastantes códigos de resultado o de error distintos aplicables a cada tipo de transacción. ¿Cómo realizar pruebas frente a todos esos posibles tipos de error? Respuesta: la mayoría de los procesadores cuentan con un sistema en el que el importe de céntimos de una transacción puede fijarse en un valor especial para desencadenar un error concreto en un entorno de pruebas (sandbox). (Por ejemplo, si el código de error para «Importe demasiado elevado» es 1243, el SDK podría permitirte provocar específicamente ese error enviando una transacción de prueba por valor de 12,43 $.) Consulta la documentación del SDK de tu proveedor para más detalles.
Muchos procesadores de pagos disponen de soluciones «in app» precertificadas (semiintegradas) que permiten encaminar los datos cifrados de la tarjeta directamente al back end, de forma más o menos transparente, manteniendo tu aplicación de pagos fuera del «alcance PCI»; otros, en cambio, dan por hecho que asumirás tú mismo las cuestiones de «alcance», en cuyo caso probablemente enviarás los datos cifrados de la tarjeta por la red hasta tu propia aplicación de servidor, detrás de un cortafuegos, donde (con ayuda de un HSM) descifrarás los datos de la tarjeta antes de encaminarlos hacia un adquirente o una pasarela.
UN EJEMPLO
Suficiente visión general. Hablemos de lo que significa, en la práctica, integrarse con un back end de pagos.
Este ejemplo concreto no será aplicable a todos los casos, evidentemente (ningún ejemplo aislado puede serlo), pero debería darte una idea de lo que probablemente te encontrarás al integrarte con un back end.
En este caso, mi tarea consistía en montar una aplicación de demostración de tipo «terminal virtual» que envía datos de transacción al servidor de pruebas de CreditCall para obtener una autorización en vivo de transacciones EMV. CreditCall dispone de una API de servidor back-end accesible a través de HTTPS mediante su ChipDNA Direct API, sobre la que, a su vez, se puede «desarrollar» utilizando un SDK en Java, C++, Perl u otros lenguajes. Yo elegí la versión de Java.
En la ChipDNA Direct sitio web, me registré para obtener una cuenta de desarrollador y rápidamente recibí (por correo electrónico) las credenciales con las que acceder al servidor de pruebas de CreditCall. También descargué el SDK de Java de CreditCall y empecé a revisar el código de ejemplo. En concreto, quería aprender a enviar transacciones EMV para su autorización. Por suerte, uno de los archivos de código de ejemplo, ExampleAuthEMV.java, mostraba precisamente el tipo de código que necesitaba.
Me puse a escribir dos clases de Java: una clase servlet para gestionar las solicitudes HTTP procedentes de un front-end basado en navegador, más una clase «worker» encargada de llevar los datos del navegador (obtenidos por el servlet) al back-end de CreditCall. La primera acabó teniendo unas 250 líneas de Java; la segunda, 92 líneas.
No voy a mostrar el código de la clase servlet, porque es prácticamente código servlet de Java estándar, salvo que toma valores TLV (enviados como valores de campos de formulario, mediante AJAX) y los coloca en un objeto java.util.Hashtable en tiempo de ejecución. Ese Hashtable se pasa después al método estático authorize() de mi clase worker. La clase worker utiliza las clases auxiliares (librería) del SDK ChipDNA Direct de CreditCall para crear un objeto com.creditcall.Request, que luego se entrega a un objeto Client, el cual a su vez llama al servidor de CreditCall. Aquí tienes el código:
Este código es tan breve y autoexplicativo que apenas merece más comentario. Lo interesante es que las clases CreditCall Solicitar y Cliente se encargan de crear los documentos XML necesarios que finalmente se envían al servidor de CreditCall. Como desarrollador, nunca tendrás que ver, tocar, parsear ni preocuparte por XML en crudo (tal y como la naturaleza manda).
Ten en cuenta que debes proporcionar las credenciales de tu cuenta de pruebas en las líneas 18 y 19. (Las credenciales mostradas arriba son falsas. ¡No intentes usar el código tal cual!) La línea 69 es donde se establece la URL del endpoint de CreditCall. La línea 72 lanza la llamada HTTPS saliente real.
El servidor de CreditCall no es especialmente exigente en cuanto a qué etiquetas TLV envías en los datos de la transacción, siempre y cuando incluyas las que contienen los datos esenciales de la tarjeta (por ejemplo: las etiquetas 5A y 57 para EMV con contacto; la etiqueta 56 para contactless; más 9F26 y 9F27, que contienen la información del criptograma). En respuesta a tus datos EMV, el servidor de CreditCall generalmente devolverá los TLV correspondientes a las etiquetas 8A, 89 y 91, y opcionalmente 71 o 72 (si hay que enviar scripts a la tarjeta chip). El código de autorización que buscas está en la etiqueta 89.
A base de prueba y error, descubrí que la aplicación servidor de CreditCall no se apresura a denegar una transacción solo porque la tarjeta presente un criptograma AAC. (Puedes determinar el tipo de criptograma inspeccionando los bits superiores de la etiqueta 9F27. Ceros indican AAC, es decir, Denegar.) Esto, no obstante, no resulta inesperado, porque la recomendación de la tarjeta no es más que eso: una recomendación. La aprobación o el rechazo final de una transacción EMV recae generalmente en el adquirente. La tarjeta puede ser (y suele ser) anulada.
Como puedes ver, se aprenden muchos detalles interesantes sobre EMV cacharreando con todo esto. ¡Nada supera realizar una autorización en vivo cuando se trata de verificar el código de una aplicación de pagos!
¿Buscas más consejos sobre transacciones EMV? Echa un vistazo a nuestra página de inicio para desarrolladores en la Knowledge Base de ID TECH. Descarga nuestro white paper sobre desarrollo EMV. O llama gratis a uno de nuestros expertos para empezar con un kit de evaluación: