API Pagos con Tarjeta (4.2507)

En este documento se especifica las caracteristicas de la API, los tipos de transacciones soportadas, la seguridad que se utiliza para la autentificación y los distintos servicios que se disponen.

Esta API, dispone servicios de pagos con tarjetas de Crédito, Débito o Prepago de las marcas: MASTERCARD, VISA y AMEX emitidas tanto en Chile como en el extranjero.

En KLAP existen dos distintos modelos de procesamiento:

• Modelo PSP en el que un Facilitador de Pago es el encargado de prestar servicios y realizar el pago a los Sub-Comercios
• Modelo Gateway donde el e-commerce realiza la negociación con KLAP y el gateway sólo responde por los protocolos de comunicación entre el e-commerce y KLAP.

Más adelante se explicará en detalle las caracteristicas de cada modelo.

Antes de ver los servicios que posee la API, se debe tener en claro las siguientes definiciones:

Autorización

Transacción que realiza validaciones para que la operación pueda realizarse exitosamente, verificando que la tarjeta esté activa, que la cuenta asociada tenga fondos suficientes, etc., y reserva el monto correspondiente a la operación.

Captura

Transacción que hace efectiva la operación previamente autorizada, cargando en la cuenta del tarjetahabiente el monto de la autorización y de las incrementales (si las hubiera) en una sola operación.

Incremental

Transacción asociada a una autorización, que incrementa el monto de la operación previamente autorizada, extendiendo a la vez el plazo para su captura.

Cargo demorado

Transacción que realiza un cargo en la cuenta del tarjetahabiente asociado a una autorización pero posterior a la captura.

Verificación de Estado de Cuenta

Transacción que permite validar la información de la cuenta del tarjetahabiente. Para efectuar esta operación, se realiza una autorización por monto cero.

Reversa

Transacción iniciada por el comercio que anula una transacción previamente realizada, por problemas como: fallo en la conexión, tiempo de espera expirado, entre otros.

Esta transacción permite anular las siguientres transacciones:

• Autorización
• Captura
• Incremental
• Cargo Demorado

Cancelación Autorización

Transacción que anula una operación previamente autorizada a solicitud del cliente.

Esta transacción sólo puede efectuarse para anular:

• Autorización

Anulación

Transacción a solicitud del tarjetahabiente que anula una operación previamente realizada por éste.

Esta transacción permite anular las siguientres transacciones:

• Captura
• Cargo Demorado

En esta API, existen dos modalidades de transacciones de Pago:

• Autorización y Captura Simultánea
• Autorización y Captura Diferida

Autorización y Captura Simultánea

En este tipo de transacción, se realiza la autorización y captura en simultáneo, se realiza enviando solamente UNA solicitud, y está permitida para tarjetas de Crédito, Débito y Prepago.

Para tarjetas de Crédito, esta operación puede efectuarse como compra normal o en cuotas, teniendo para ello las siguientes opciones:

• Cuotas financiadas por el comercio
• Cuotas financiadas por el emisor

Autorización y captura diferida

Este tipo de transacción, es posible generar una transacción de autorización cierto día y realizar el envío de la captura correspondiente a la operación algún día posterior (dentro de los plazos establecidos para ello), y está permitida para tarjetas de Crédito, Débito y Prepago.

Para tarjetas de Crédito, esta operación puede efectuarse como compra normal o en cuotas, teniendo para ello las siguientes opciones:

• Cuotas financiadas por el comercio
• Cuotas financiadas por el emisor

Esto también conlleva que se pueda incrementar el monto anteriormente autorizado y previamente a realizar la captura, o pueda realizar un cobro posterior a la captura mediante el servicio de cargo demorado.

ReAutorización y Captura Simultánea

Una ReAutorización y Captura Simultánea es una compra iniciada por el comercio después de una compra original y se rige por las mismas condiciones que Authorización y Captura Simultánea.

Los casos comunes que requieren reautorizaciones incluyen envíos retrasados, envíos divididos, estadías prolongadas o alquileres prolongados.

ReAutorización y Captura Diferida

Una ReAutorización y Captura Diferida es una compra iniciada por el comercio después de una compra original y se rige por las mismas condiciones que Authorización y Captura Diferida.

Los casos comunes que requieren reautorizaciones incluyen envíos retrasados, envíos divididos, estadías prolongadas o alquileres prolongados.

Duración y Tolerancia

Autorizacion y Captura Diferida

La cantidad de días y el porcentaje de tolerancia que puede transcurrir entre una autorización y una captura viene dado en la siguiente tabla:

VISA
Descripción	MCC	Duración	Tolerancia
Car Rental Agencies	3351 - 3500	31	15%
Lodging—Hotels, Motels, Resorts	3501 - 3999	31	15%
Transporte Local y Suburbano de Pasajeros que Viajan Diariamente	4111	7	0%
Ferrocarriles de pasajeros	4112	7	0%
Taxis y Limosinas	4121	1	20%
Líneas de Omnibus	4131	7	0%
Steamship and Cruise Lines	4411	31	15%
Tiendas de Víveres y Supermercados	5411	7	15%
Electric Vehicle Charging merchants	5552	7	0%
Sitios para comer y Restaurantes	5812	7	20%
Sitios para Beber	5813	7	20%
Hoteles	7011	31	15%
Trailer Parks and Campgrounds	7033	7	0%
Equipment Tool, furniture and appliance rental	7394	7	0%
Automobile Rental Agency	7512	31	15%
Truck and Utility Trailer Rentals	7513	31	15%
Motor Home and Recreational Vehicle Rentals	7519	7	0%
Estacionamientos, Parquímetros y Garajes	7523	7	0%
Amusement Parks, Circuses, Carnivals, and Fortune Tellers	7996	7	0%
Recreation Services	7999	7	0%
Otros MCC		7	15%
MASTERCARD
Descripción	MCC	Duración	Tolerancia
Todos los MCC		30	15%
AMEX
Descripción	MCC	Duración	Tolerancia
Todos los MCC		7	10%

Cargo Demorado

Se pueden realizar cargos demorados hasta 90 días después de la captura.

ReAutorizacion y Captura Diferida y ReAutorizacion y Captura Simultánea

La cantidad de días que puede transcurrir entre una autorización y una reautorización viene dado en la siguiente tabla:

VISA
Descripción	MCC	Duración
Car Rental Agencies	3351 - 3500	120
Lodging—Hotels, Motels, Resorts	3501 - 3999	120
Steamship and Cruise Lines	4411	120
Boat Rentals and Leasing	4457	120
Hoteles	7011	120
Trailer Parks and Campgrounds	7033	120
Equipment Tool, furniture and appliance rental	7394	120
Automobile Rental Agency	7512	120
Truck and Utility Trailer Rentals	7513	120
Motor Home and Recreational Vehicle Rentals	7519	120
Recreation Services	7999	120
Otros MCC		90

• Los Montos deben estar en Pesos Chilenos (ISO 4217 = CLP)
• No soporta CORS

Reglas de la API

• El campo consumer_transaction_id debe ser único (incluso en días y transacciones distintas).
• Todos los requerimientos deben ser realizados sobre HTTPS TLS 1.2. Los requerimientos sobre HTTP fallarán.
• Los campos del nodo card deben ser encriptados utilizando el algoritmo AES-256. El procedimiento para compartir la llave se acordará en otro documento.
• Todos los requerimientos son autenticados. Debe incluir el encabezado Api-Key: <key>.

Idempotencia

La API soporta idempotencia, por lo tanto puedes reintentar un requerimiento sin peligro de que el recurso se cree dos veces. Para esto debes incluir el encabezado Idempotency-Key: <key>, donde key es un identificador único de tu sistema o UUID. La clave tiene una validez de 24 horas.

Gestión de llaves

Los campos del nodo card se deben enviar encriptados por una llave simétrica utilizando el algoritmo AES-256. Para establecer la llave simétrica, el comsumidor de la API debe generar y enviar a KLAP un componente de la llave con sus respectivos dígitos de chequeo. KLAP generará y enviará otro componenente. Luego, ambos actores deberán cargar los componentes en sus HSMs, generando la llave final y verificando que los digitos de chequeo coincidan. Esta llave debe ser cambiada cada 3 años.

Versión 1.0

• Modelo PSP
• Transacciones con tarjeta MASTERCARD
• Transacciones con tarjeta de Crédito
• Pagos Recurrentes
• Pagos Card-on-File (CoF)
• Cuotas Comercio
• Cuotas Emisor

Versión 1.1

• Transacciones con tarjeta VISA
• Transacciones con tarjeta de Débito y Prepago

• Modelo Gateway
• Autorización y Captura Diferida
• Incremental
• Demorado
• Verificación de Estado de Cuenta
• Autorización y Captura Diferida (Crédito, Débito y Prepago)

Version 3.2109

• Se agrega campos code y message a respuesta 200
• Campo card opcional en transacciones subsiguientes.

Version 3.2112

• Anulación Parcial MASTERCARD y VISA
• Se agrega campo branch_id y terminal_id para soportar varias sucursales y terminales en modelo PSP y Gateway

Versión 3.2203

• Consulta de Transacción por el campo consumer_transaction_id o por el campo mc_code

Versión 4.2207

• 3D-Secure con MPI externo para VISA y MASTERCARD. Se agrega objeto three_dsen la solicitud y respuesta.
  • En la solicitud contiene los campos necesarios para enviar una transacción ya autenticada.
    
  • En la respuesta contiene el mensaje recibido de una solictud de una transacción ya autenticada, incluye los campso eci el valor del ECI y cavv_result_code el resultado del Criptograma de Autenticación.

Versión 4.2210

• Se agrega nuevos campos en la respuesta:
  • cvv_result contiene el resultado cuando el CVV es enviado.
  • brand contiene la marca de la tarjeta (Mastercard, Visa, Maestro, American Express, o UnionPay).
• Se agregan codigos de respuesta para Mastercard y Maestro
• Se agregan nuevos códigos de respuesta de Klap y del release de Mastercard y Maestro:

  KLAP
  Código	Mensaje
  K002013	TRX CON TARJETA INTERNACIONAL EN UN SUBCOMERCIO INTERNACIONAL.
  K002014	DIRECTORY SERVER TRANSACTION ID IS NOT ALLOWED.
  MASTERCARD
  Código	Mensaje
  B240051	EXCEDE SALDO MAXIMO - REINTENTE EN 1 HORA
  B250051	EXCEDE SALDO MAXIMO - REINTENTE EN 24 HORAS
  B260051	EXCEDE SALDO MAXIMO - REINTENTE EN 2 DIAS
  B270051	EXCEDE SALDO MAXIMO - REINTENTE EN 4 DIAS
  B280051	EXCEDE SALDO MAXIMO - REINTENTE EN 6 DIAS
  B290051	EXCEDE SALDO MAXIMO - REINTENTE EN 8 DIAS
  B300051	EXCEDE SALDO MAXIMO - REINTENTE EN 10 DIAS
  MAESTRO
  Código	Mensaje
  M240051	EXCEDE SALDO MAXIMO - REINTENTE EN 1 HORA
  M250051	EXCEDE SALDO MAXIMO - REINTENTE EN 24 HORAS
  M260051	EXCEDE SALDO MAXIMO - REINTENTE EN 2 DIAS
  M270051	EXCEDE SALDO MAXIMO - REINTENTE EN 4 DIAS
  M280051	EXCEDE SALDO MAXIMO - REINTENTE EN 6 DIAS
  M290051	EXCEDE SALDO MAXIMO - REINTENTE EN 8 DIAS
  M300051	EXCEDE SALDO MAXIMO - REINTENTE EN 10 DIAS

Versión 4.2211

• Se deja el campo merchant.local_tax_number como campo requerido cuando el campo merchant.country_code es igual a 152.

Versión 4.2303

• Se agregan los campos cryptogram_value, eci y token_requestor_id para recibir información de tokenización.
  • El campo eci tendrá prioridad por sobre al campo three_ds.eci.
  • En caso de no recibir el campo eci, se utilizará el que se encuentra dentro del objeto three_ds.
  • En caso de no recibir ninguno de los dos campos se enviará: 0 - Not Authenticated.

Versión 4.2305

• Mejoras en el framework de MIT y CIT:
  • Objeto charge_type queda opcional.
  • Campo para identificar iniciador de transacción charge_type.initiator, valores posibles: consumer si la transaccion es iniciada por el tarjetahabiente o merchant si es iniciada por el comercio.
  • Campo para soportar tipo de transaccion charge_type.type, valores posibles: oneoff si es una compra única, recurring si es un pago recurrente o card_on_file si es un pago con la tarjeta almacenada.
• Verificación de Estado de Cuenta: Se agrega objeto charge_type.

Versión 4.2306

• Se agrega campo trx_id en al respuesta que corresponde al identificador generado por las marcas (Visa o Mastercard).

Versión 4.2307

• Se agrega campo charge_type.auth_type en la solicitud cuyos valores posibles son: "total" o "partial" y su valor por defecto es total

Versión 4.2309

• Se agrega Transacciones del framework MIT: Reauthorización.
• Para transacciones del framework MIT, se agrega el campo consumer_related_transaction_id que corresponde al consumer_transaction_id de la transacción original que debe ser enviado en conjunto con el campo charge_type.mit_industry_practice en la solicitud cuyo valor posible es: "reauthorization" y su valor por defecto es null.
• Se agrega código de rechazo por bloqueo de reintentos por reglas de Visa y Mastercard.
• Se agrega el campo installments en la transacción de Autorización y Captura Diferida.
• Se agrega la cantidad y tipo de cuotas en la respuesta.

Versión 4.2401

• Se agrega recurring_payment para soportar información adicional de transacciones recurrentes.
• Se agregan nuevos códigos de respuesta de Klap:

  KLAP
  Código	Mensaje
  K000913	CUOTAS NO PERMITIDAS PARA TARJETA INTERNACIONAL
  K000914	REFUND PARTIAL NO PERMITIDO, TRX CUOTAS COMERCIO
  K003020	MARCA DE TARJETA NO SOPORTADA
  K003058	RECHAZADA- REINTENTAR EL YYYY-MM-DD A LAS HH:MM
  K007001	CÓDIGO MC DE LA TRANSACCIÓN MIT RELACIONADA NO EXISTE.
  K007002	TIPO DE TRANSACCION MIT NO PERMITIDA.
  K007003	TRANSACCIÓN MIT EXCEDE EL TIEMPO PERMITIDO PARA EL MCC ASOCIADO.
  K007004	TRANSACCIÓN MIT RELACIONADA NO ESTÁ APROBADA.
  K007005	TRANSACCIÓN MIT RELACIONADA POSEE UN CÓDIGO DE RESPUESTA INVÁLIDO.
  K008001	INCONSISTENCIA DE DATOS CON TRANSACCION AFD
  K008002	ERROR DE INTEGRIDAD DE DATOS DE MIT O CIT
  K099062	POS DATA INVÁLIDA

Versión 4.2407

• Otras transacciones del framework MIT: No Show, Resubmission, y Delayed Charge.
• Se agrega campo charge_type.market_specific que permite solicitar la extensión de la autorización a 30 días, y su campo de respuesta de dicha solicitud charge_type.auth_extended_result. Ambos campos aplican solamente en autorización y captura diferida con tarjeta Visa.
• Se agrega campo merchant.country_code_origin para transacciones de subcomercios o entidades gubernamentales.

Versión 4.2501

• Transacciones con tarjeta American Express.
• Se cambia longitud de trx_id en la respuesta de 20 caracteres a 50 caracteres.
• Se agregan para el Modelo PSP los siguientes campos:
  • merchant.postal_code
  • merchant.country_subdivision
  • merchant.url
  • merchant.customer_service_phone
  • merchant.phone
  • merchant.latitude
  • merchant.longitude

Versión 4.2504

• Se agrega el campo trx_id que permite relacionar transacciones MIT enviando el campo Transaction Link ID de Mastercard, el Transaction ID de Visa o el Original Transaction ID de American Express.

Versión 4.2506

• Se agrega el campo brand_merchant_id que permite enviar el identificador único del comercio registrado con la marca que corresponde al MVV de Visa o al MAID de Mastercard.

Versión 4.2507

Se agrega definición para enviar transacciones con Token de Red. Para mayor información, ir a la sección ¿Cómo se encripta el campo card?

Versión 4.2xxx

• Tokenización con tarjeta American Express.

El campo consumer_transaction_id es el identificador único por transacción y con este campo se realiza la vinculación entre Autorización y Captura, Reversas, Anulaciones, entre otros. Por lo tanto, este campo debe ser único incluso en días y transacciones distintas.

Por ejemplo:

"consumer_transaction_id": "935f4328-8217-405a-a22b-8464fa7aac9e"

Todos los requerimientos son autenticados. Debe incluir el encabezado Api-Key.

Por ejemplo:

Api-Key: YHw0yzEef0KnFD

Idempotency Key es un identificador único que dado a su propiedad, permite enviar dos o más veces una transacción idéntica y así conseguir el mismo resultado que se realizó en primera instancia.

Esta propiedad, permite re-intentar una transacción que haya sido aprobada, pero que ha tenido una interrupción entre el cliente y la API, enviando una nueva solicitud con los mismos valores para Idempotency-Key y de los datos en el cuerpo del mensaje.

Este valor es asignado en la cabecera de la solicitud de la siguiente manera Idempotency-Key

Por ejemplo:

Idempotency-Key: 935f4328-8217-405a-a22b-8464fa7aac9e

Los requerimientos deben ser realizados sobre HTTPS sobre TLS 1.2 o superior.

En el cuerpo del mensaje existe un campo card en el que se envian los datos. Éstos debe ser encriptados utilizando el algoritmo AES-256.

Por ejemplo:

"card": "mOoT6vkSI7z0ahhF7kN32cXAshL26UYHw0yzEef0KnFDbhtQRv6b1hoMkmdOCQsg"

El campo card corresponde a los datos de la tarjeta encriptados, puede ser PAN o Token de Red:

PAN

Para encriptar los datos de la tarjeta, se debe enviar como una cadena de caracteres concatenada el Número de la Tarjeta o Primary Account Number (PAN), Fecha de Expiración de la tarjeta (formato aamm), Nombre del Tarjetahabiente impreso en la tarjeta, y de manera opcional el CVV (Card Validation Value) que generalmente se encuentra impreso al reverso de la tarjeta.

El formato para enviar a encriptar los datos del PAN debe ser el siguiente:

sin CVV	«PAN»|«ExpirateDate»|«NameOnCard»
con CVV	«PAN»|«ExpirateDate»|«NameOnCard»|«CVV»

Network Token

Para encriptar los datos del Token, se debe enviar como una cadena de caracteres concatenada el Número de la Token de Red o Network Token, Fecha de Expiración del Token (formato aamm), Nombre del Tarjetahabiente impreso en la tarjeta, y de manera opcional el DTVV (Dynamic Token Verification).

El formato para enviar a encriptar los datos del Token debe ser el siguiente:

sin DTVV	«Token»|«TokenExpirateDate»|«NameOnCard»
con DTVV	«Token»|«TokenExpirateDate»|«NameOnCard»|«DTVV»

Modelo PSP

Actualmente en el modelo PSP (Payment Service Provider) para el Data Element-43 se enviará: el nombre del PSP de un largo máximo de 12 caracteres, más el nombre del comercio asociado al campo merchant.name y lo que se incluya en el campo additional_data.soft_descriptor.

Por ejemplo: Si el nombre del PSP es PAYMENT y en el cuerpo del mensaje en el campo merchant.name se envía: Store 123 y additional_data.soft_descriptor se envía Compra 12345, para este caso el soft-descriptor será:

  PAYMENT*STORE 123 Compra 12345

Modelo Gateway

Para el modelo Gateway para el Data Element-43 se enviará: el nombre del comercio, y lo que se incluya en el campo additional_data.soft_descriptor.

Por ejemplo: Si el nombre del comercio es KLAP y en el campo additional_data.soft_descriptor se envía Compra 12345, para este caso el soft-descriptor será:

  KLAP Compra 12345

En el Soft-Descriptor (Data Element-43) hacia la marca de la tarjeta sólo se podrá enviar los primeros 14 caracteres.

• El Cobro Card-on-File corresponde a una transacción donde el tarjetahabiente autoriza al comercio almacenar los datos de la tarjeta, para posteriormente autorizar uno o más cobros por algun servicio, o producto.
• La transaccion de almacenamiento de la tarjeta debe incluir el Card-Verfication-Value o CVV, en el campo charge_type.initiator debe ir cardholder y en el campo charge_type.type debe ir card_on_file.

Por ejemplo:

  "charge_type": {
    "initiator": "cardholder",
    "type": "card_on_file"
  }

• La transaccion card-on-file subsecuente de la tarjeta debe incluir en el campo charge_type.initiator debe ir merchant y en el campo charge_type.type debe ir card_on_file.

Por ejemplo:

  "charge_type": {
    "initiator": "merchant",
    "type": "card_on_file"
  }

• El Cobro Recurrente corresponde a una serie de pagos en plazos y acordados previamente con el tarjetahabiente, estos cobros generalmente están asociados a servicios digitales o físicos.
• El primer cobro debe incluir el Card-Verfication-Value o CVV, en el campo charge_type.initiator debe ir cardholder y en el campo charge_type.type debe ir recurring.

Por ejemplo:

  "charge_type": {
    "initiator": "cardholder",
    "type": "recurring"
  }

• Para un cobro subsecuente, en el campo charge_type.initiator debe ir merchant y en el campo charge_type.type debe ir recurring.

Por ejemplo:

  "charge_type": {
    "initiator": "merchant",
    "type": "recurring"
  }

• Una ReAutorización corresponde a una transacción iniciada por el comercio acordada previamente con el tarjetahabiente mediante una transacción de registro o compra anterior.
• En el primer cobro debe ser efectuado el tarjetahabiente.

Por ejemplo:

  "charge_type": {
    "initiator": "cardholder",
    "type": "card_on_file"
  }

• Para un cobro de reautorización, en el campo charge_type.initiator debe ir merchant, y en el campo charge_type.mit_industry_practice debe ir reauthorization.

Por ejemplo:

  "consumer_related_transaction_id":"86cfbc4c-399a-4aa8-b84a-4dbd8886ec7d",
  "charge_type": {
    "initiator": "merchant",
    "mit_industry_practice": "reauthorization"
  }

• Se puede realizar una Autorización y Captura Diferida y luego una ReAutorización y Captura Simultánea y viceversa.

Se rechazarán por Klap reintentos no permitidos por la marca, con el mensaje RECHAZADA- REINTENTAR EL DD-MM-AAAA A LAS HH:MM donde DD-MM-AAAA corresponde al dia, mes y año, y HH:MM la hora y minutos en que se puede volver a reintentar la transacción.

Mastercard:

• Se rechazará todo intento de transacción a partir del octavo reintento rechazado en adelante, en un tiempo de 24 horas, y se permitirá hasta 35 reintentos dentro de 30 días de realizada la transacción original. Los criterios que la marca utiliza para identificar un reintento es a través del código de comercio y el número de tarjeta.
• Se rechazará todo reintento del mismo monto de transacción que haya sido rechazada con MAC 03 o 21 durante 30 días. Los criterios que la marca utiliza para identificar un reintento es a través del código de comercio, el número de tarjeta y monto de la transacción.

Visa:

• Se rechazará todo reintento de transacción que haya sido rechazada con código de respuesta perteneciente a la Categoría 1 durante 30 días de realizada la transacción original. Los criterios que la marca utiliza para identificar un reintento es a través del código de comercio y el número de tarjeta.
• Se rechazará todo intento de transacción a partir del reintento número 16 rechazado en adelante (dentro de las Categorías 2, 3 y 4), en un tiempo de 30 días de realizada la transacción original. Los criterios que la marca utiliza para identificar un reintento es a través del código de comercio y el número de tarjeta.

Categorías

• Categoría 1: Emisor nunca aprobará la transacción

  • V000004: CUENTA CERRADA- NO REINTENTE
  • V000007: CUENTA CERRADA- NO REINTENTE
  • V000012: TRANSACCION INVALIDA- NO REINTENTE
  • V000014: TARJETA INVALIDA- CONTACTE A SU EMISOR
  • V000015: EMISOR INVALIDO- NO REINTENTE
  • V000041: TARJETA BLOQUEADA- CONTACTE A SU EMISOR
  • V000043: TARJETA BLOQUEADA- CONTACTE A SU EMISOR
  • V000046: Cuenta Cerrada
  • V000057: TRANSACCION NO PERMITIDA POR EMISOR
  • V0000R0: RECHAZADA- CONTACTE A SU EMISOR
  • V0000R1: RECHAZADA- CONTACTE A SU EMISOR
  • V0000R3: RECHAZADA- CONTACTE A SU EMISOR

• Categoría 2: Emisor no puede aprobar en este momento la transacción

  • V000003: COMERCIO INVALIDO- RESTRINGIDO POR EMISOR
  • V000019: REINTENTE- EMISOR NO DISPONIBLE
  • V000051: EXCEDE SALDO MAXIMO
  • V000059: RECHAZADA- CONTACTE A SU EMISOR
  • V000061: EXCEDE SALDO MAXIMO
  • V000062: TARJETA RESTRINGIDA EMISOR
  • V000065: EXCEDE MAXIMO DE TRANSACCIONES
  • V000075: EXCEDE INTENTOS DE PIN PERMITIDOS
  • V000078: Bloqueada / Primer uso o Condicion Especial
  • V000086: PIN INVALIDO
  • V000091: RECHAZADA- SISTEMA EMISOR NO OPERATIVO
  • V000093: TRANSACCION RESTRINGIDA POR EMISOR
  • V000096: RECHAZADA- SISTEMA EMISOR NO OPERATIVO
  • V0000N3: TRANSACCION NO PERMITIDA POR EMISOR
  • V0000N4: EXCEDE SALDO MAXIMO

• Categoría 3: Calidad de Datos Ingresados

  • V00001A: SE REQUIERE INFORMACIÓN ADICIONAL DE CLIENTE
  • V000054: TARJETA EXPIRADA
  • V000055: PIN INVALIDO
  • V000082: CODIGO DE SEGURIDAD INVALIDO
  • V0000N7: CODIGO DE SEGURIDAD INVALIDO

• Categoría 4: Codigo Genérico de Respuesta del Emisor

  • V000005: RECHAZADA- CONTACTE A SU EMISOR

• Una transacción tokenizada corresponde a una transacción donde el campo card es reemplazado por un token de red.

• Para una transacción inicial se debe enviar en el campo charge_type.initiator debe ir cardholder y en el campo charge_type.type debe ir recurring o card_on_file.

Por ejemplo:

  "charge_type": {
    "initiator": "cardholder",
    "type": "recurring"
  }

• Para un cobro subsecuente, en el campo charge_type.initiator debe ir merchant y en el campo charge_type.type debe ir recurring o card_on_file, y para tener una mayor conversión se puede enviar el campo consumer_related_transaction_id.

Por ejemplo:

  "consumer_related_transaction_id": "935f4328-8217-405a-a22b-8464fa7aac9e",
  "charge_type": {
    "initiator": "merchant",
    "type": "recurring"
  }

En este modelo, el Facilitador de Pago o PSP, es el encargado de prestar servicios que incluyen la liquidación y/o pago de las sumas que corresponden a cada sub-commercio por concepto de las transacciones efectuadas con tarjetas de pago a través de la API.

Cada PSP está encargado de pagar a cada uno de los sub-comercios asumiendo esta responsabilidad frente a KLAP.

Para este modelo, KLAP proporcionará una Api-Key la cual será utilizada unicamente por el PSP, la cual es secreta e intransferible. Y debe ser proporcionada en cada solicitud que se realice.

La sección Financiero corresponde a las transacciones solicitadas a voluntad del comercio o del tarjetabiente.

En este modelo, el Facilitador de Pago o PSP, es el encargado de prestar servicios que incluyen la liquidación y/o pago de las sumas que corresponden a cada sub-commercio por concepto de las transacciones efectuadas con tarjetas de pago a través de la API.

Cada PSP está encargado de pagar a cada uno de los sub-comercios asumiendo esta responsabilidad frente a KLAP.

Para este modelo, KLAP proporcionará una Api-Key la cual será utilizada unicamente por el PSP, la cual es secreta e intransferible. Y debe ser proporcionada en cada solicitud que se realice.

La sección Reversa corresponde a las transacciones solicitadas por el PSP para revertir el estado de una transacción.