EMVCo – Merchant-Presented QR

EMVCo QR Code Esta vez vamos a presentar un resumen de como trabajar con el estándar EMVCo QR, para comenzar, este estándar busca proporcionar especificaciones relacionadas con el uso de QR para los pagos digitales, en este sentido tenemos dos modalidades: Consumer-Presented, esta modalidad implica que el cliente del comercio muestre el QR al comercio para realizar la transacción de pago; es decir, la persona genera su código QR desde su dispositivo móvil para que el comercio, a través de un escaner, pueda realizar la lectura y disparar la transacción de pago. Merchant Presented, aquí el que muestra el código QR es el comercio y el cliente desde su aplicación móvil va realizar la lectura e iniciar la transacción de pago. En este post veremos con más detalle como se estructura la segunda modalidad y veremos un ejemplo práctico. En primera instancia, debemos conocer los conceptos y estructura de esta especificación, para esto debemos mencionar como se compone el QR Code. QR Code Payload Se compone de cinco secciones según lo indicado en el EMVCo y tiene lo siguiente: Convenciones usadas para el contenido del código QR Información de la cuenta del comercio Información adicional del comercio Información del valor de la transacción Datos adicionales para el apoyo de diversos casos de uso Cada una de estas secciones contiene objetos (Data Object) que van a permitir formar la trama completa y ser enviados a la transacción de pago, debajo se mostrará una tabla con cada uno de estos campos y al final de este post verán como se lee cada uno de estos objetos. Data Objects – Posición, Formato y longitud ID’s Formato Longitud 1. QR Code Conventions Payload Format Indicator “00” N “02” Point of Initiation Method “01” N “02” Cyclic Redundancy Check (CRC) “63” ans “04”   ID’s Formato Longitud 2. Merchant Account Information (*) Merchant Account Information “02”-“51” ans var. up to “99” (*) Información correspondiente al comercio que se desglosa en otra tabla más adelante de este post ID’s Formato Longitud 3. Additional Merchant Information Merchant Category Code “52” N “04” Country Code “58” ans “02” Merchant Name “59” ans var. up to “25” Merchant City “60” ans var. up to “15” Postal Code “61” ans var. up to “10” Merchant Information-Alternate Language “64” S var. up to “99”   ID’s Formato Longitud 4. Transaction Value Transaction Amount “54” ans var. up to “13” Transaction Currency “53” N “03” Tip or Convenience Indicator “55” N “02” Value of Convenience Fee Fixed “56” ans var. up to “13” Value of Convenience Fee Percentage “57” ans var. up to “05”   ID’s Formato Longitud 5. Additional Data Objects “62” S var. up to “99” Bill Number “01” ans var. up to “25” Mobile Number “02” ans var. up to “25 “ Store Label “03” ans var. up to “25” Loyalty Number “04” ans var. up to “25” Reference Label “05” ans var. up to “25” Customer Label “06” ans var. up to “25” Terminal Label “07” ans var. up to “25” Purpose of Transaction “08” ans var. up to “25” Additional Consumer Data Request “09” ans var. up to “03” Data Objects – Merchant Account Information El campo de información de la cuenta del comercio (Merchant Account Information) puede trabajarse bajo múltiples redes de pagos; es decir, puede trabajar con Visa, MasterCard o cualquier sistema de pago EMV de forma simultánea, de igual forma, se puede trabajar con sistemas de pagos que no pertenezcan al sistema EMV, como pueden ser redes locales (Por ejemplo: Tunki). Debajo se muestra la estructura de este campo. ID’s Merchant Account Information “02”-“03” Reserved for Visa “04”-“05” Reserved for Mastercard “06”-“08” Reserved by EMVCo “09”-“10” Reserved for Discover “11”-“12” Reserved for Amex “13”-“14” Reserved for JCB “15”-“16” Reserved for UnionPay “17”-“25” Reserved by EMVCo “26”-“51” Templates reserved for additional payment Se utilizará un ID de Merchant Account Information para el sistema de pagos primitivo (“02”-”25”) cuando sea este quien asigne la información de cuenta del comercio a través de un identificador implícito (Identificador de Visa/MC/AMEX, etc). Para los campos reservados para sistema de pagos adicionales (“26”-”51”) se utilizan a través de plantillas, donde el campo “Globally Unique Identifier” debería tener un valor que contenga al menos uno de los siguientes puntos: Un Application Identifier (AID), que cumpla con el estándar ISO 7816-4. Por ejemplo: “D840000000” Un [UUID] sin separadores. Por ejemplo: “581b314e257f41bfbbdc6384daa31d16” Un DN reservado. Por ejemplo: “com.merchant.name” ID’s Additional Payment Formato Longitud “00” Globally Unique Identifier ans var. up to “32” “01”-“99” Payment network specific S var. up to “99” Organización de los datos Con cada objeto de datos mencionados arriba se puede construir la  trama que nos permita realizar a transacción de pago a través del QR y bajo el estándar de EMVCo. La formación de estos datos siempre debe seguir el siguiente orden:   Ejemplo 1: Transacción básica Para este caso sería un funcionalidad básica donde el cliente realiza el escaneo del QR a través de su aplicación móvil y procesa la transacción derivándola hacia el adquiriente o procesador para su autorización del pago, una vez efectuado el pago, se envía la confirmación (o rechazo) de la operación al comercio y al cliente. Para este escenario tenemos la siguiente estructura de la trama EMVCo. Data Object Formato ID Longitud Valor Payload Format Indicator N “00” “02” “01” Merchant Account Information ans “02” “16” “4000123456789012” Merchant Category Code N “52” “04” “5251” Transaction Currency N “53” “03” “840” Country Code ans “58” “02” “ES” Merchant Name ans “59” “19” “SKILLS & EXPERIENCE” Merchant City ans “60” “09” “BARCELONA” Cyclic Redundancy Check (CRC) ans “63” “04” Calculado usando un algoritmo El código QR generado por el comercio y leído por el aplicativo se traduce en lo siguiente: 000201021640001234567890125204525153038405802PE5919SKILLS+&+EXPERIENCE6009BARCELONA630425B4 Ejemplo 2: Múltiples redes de pagos En este ejemplo, el cliente va tener la posibilidad de realizar el pago a través de diversos sistemas de pagos (EMV o no-EMV). Para intentar entenderlo mejor podemos ver el siguiente gráfico: Para este escenario tenemos la siguiente estructura de la trama EMVCo: Data Object Formato ID Longitud Valor Payload Format Indicator N “00” “02” “01” Merchant Account Information ans “02” “16” “4000123456789012” Merchant Account Information ans “26” “40″ • Globally Unique ID ans “00” “12” D15600000000 • Merchant ID S “01” “20” A93FO3230QDJ8F93845K Merchant Category Code N “52” “04” 5251 Transaction Currency N “53” “03” 840 Transaction Amount ans “54” “13” 0000000000010 Country Code ans “58” “02” ES Merchant Name ans “59” “19” “SKILLS & EXPERIENCE” Merchant City ans “60” “09” “BARCELONA” Cyclic Redundancy Check (CRC) ans “63” “04” Calculado usando un algoritmo El código QR generado por el comercio y leído por el aplicativo se traduce en lo siguiente: 0002010216400012345678901226400012D156000000000120A93FO3230QDJ8F93845K 520452515303840541300000000000105802PE5919SKILLS+&+EXPERIENCE6009BARCELONA630425B4 Para mayor información sobre este estándar pueden recurrir a las especificaciones en el siguiente enlace.