Acepta pagos con tarjeta de crédito y débito en Chile 🇨🇱: cargos únicos, Cuotas Comercio, Cuotas Emisor, flujos de preautorización y network tokens.La API de Card te permite tokenizar los datos de la tarjeta y procesar pagos de forma segura. Kushki maneja toda la información sensible de la tarjeta: tu servidor solo trabaja con tokens.
Se requiere la Private Key
La generación del token requiere tu Private Key (Private-Merchant-Id). Nunca la expongas en código del lado del cliente ni del frontend: llama siempre al endpoint de token desde tu backend.
Llama a POST /card/v1/tokens desde tu backend con los datos de la tarjeta y el monto total. Devuelve un token de un solo uso, válido para un único cargo.
⚠️ Expiración del token: Los tokens expiran en poco tiempo. Úsalos de inmediato: no los guardes para después.
2
Haz un cargo
Llama a POST /card/v1/charges con el token y el desglose del monto. Incluye contactDetails y, opcionalmente, orderDetails y productDetails para el scoring antifraude.
Chile admite dos tipos de diferido. Llama siempre primero al endpoint de opciones de diferido para verificar que el BIN de la tarjeta admite cuotas y para obtener las opciones de meses válidas.
⚠️ Beta: Cuotas Comercio (creditType03) está en fase Beta para Chile. La estructura de datos y la lógica pueden cambiar sin aviso previo. Contacta al equipo de Kushki para habilitar esta funcionalidad.
El comercio absorbe el costo de las cuotas. Envía el objeto deferred con creditType: "03". Disponible de 2 a 12 meses. Los tres campos (graceMonths, creditType y months) son obligatorios.
Usa la preautorización para reservar fondos sin capturarlos de inmediato: es ideal para flujos de hotelería, arriendo de autos o marketplace.
1
Autoriza
POST /card/v1/preAuthorization: reserva fondos en la tarjeta. Devuelve un ticketNumber.En Chile la autorización expira después de:
28 días para tarjetas de crédito
7 días para tarjetas de débito
2
Reautoriza (opcional)
POST /card/v1/reauthorization: extiende el monto o el efecto de la autorización original. Envía el ticketNumber original. La moneda debe coincidir con la de la autorización original.
Si el pago no se captura dentro de 7 días (débito) o 28 días (crédito), el banco emisor puede devolverle al tarjetahabiente los fondos retenidos.
3
Captura
POST /card/v1/capture: captura los fondos reservados (monto total o parcial). Usa el ticketNumberde la autorización, no de una reautorización.
El monto máximo a capturar puede ser hasta un 10% mayor que la autorización inicial más las reautorizaciones que no se hayan cancelado.
4
Anula (si no vas a capturar)
DELETE /v1/charges/{ticketNumber}: cancela la autorización y libera los fondos reservados. Una vez cancelada, no se pueden hacer reautorizaciones sobre esa transacción.
Devuelve los fondos al tarjetahabiente después de la liquidación.
En Chile, tanto la anulación como el reembolso admiten montos totales y parciales. Para una operación parcial, incluye el objeto amount en el cuerpo del request.
Cargos recurrentes y validación de tarjeta (transactionMode)#
Incluye transactionMode en la solicitud de token para flujos recurrentes o para validar la tarjeta con monto cero. Disponible solo bajo el modelo Acquirer.
Valor
Descripción
initialRecurrence
Primera transacción de una serie recurrente. Envía los datos completos de la tarjeta (número, expiración, CVV) para registrarla.
subsequentRecurrence
Cargos recurrentes posteriores: puedes omitir el CVV una vez que se procesó un initialRecurrence.
accountValidation
Validación de tarjeta con monto cero. Pon totalAmount en 0 y después llama a POST /card/v1/validation.
Si tienes tu propio motor de suscripciones (solo comercios con PCI Compliance), procesa los cargos recurrentes así:
1
Registra la tarjeta
Solicita un token con transactionMode: "initialRecurrence".
2
Haz el cargo inicial
Cobra con ese token y guarda el transactionReference de la respuesta.
3
Tokeniza para los cargos siguientes
Solicita un token con transactionMode: "subsequentRecurrence".
4
Cobra las transacciones subsecuentes
Envía el transactionReference que guardaste en el campo initialRecurrenceReference del request del cargo.
Para Mastercard, incluye citMit como campo informativo cuando proceses suscripciones externas. Los valores son C101–C104 para transacciones iniciadas por el cliente y M101–M104, M205–M208 para las iniciadas por el comercio.
POST /card/v2/charges acepta los datos de la tarjeta directamente en el cuerpo del request, sin necesidad de una llamada previa de token. Es para integraciones server-to-server en las que ya tienes los datos de la tarjeta.
Servicio On-demand — requiere PCI DSS
Los endpoints sin token solo están disponibles para empresas con PCI DSS compliance, bajo el modelo Acquirer. Contacta a Kushki antes de habilitarlos.
Limitaciones:
Solo disponible para Visa y Mastercard.
No es compatible con las herramientas antifraude Siftscience ni TransUnion.
No es compatible con la herramienta de autenticación 3DS de Kushki: usa tu propio motor 3DS.
No es compatible con la autenticación OTP de Kushki.
BETAChile admite procesar transacciones con tarjetas tokenizadas por la red (tokens provisionados por Visa o Mastercard a través de billeteras digitales como Apple Pay).Pon isNetworkToken: true e incluye el objeto networkToken:
Campo
Descripción
deviceType
Tipo de dispositivo desde el que se origina la transacción tokenizada
requestorId
ID único que la red de tarjetas le asigna al solicitante del token
source
Origen del token
walletId
Identificador de la billetera digital: "01" para Apple Pay, "04" para otras billeteras
authenticationLevel
Nivel de autenticación realizado durante el provisionamiento del token
mvv
Merchant Verification Value de 10 dígitos (solo Visa)
Incluye también cryptogram en el objeto de la tarjeta cuando el network token traiga un cryptogram de la billetera o del servicio de tokenización del emisor. El valor debe tener entre 20 y 28 caracteres alfanuméricos.
⚠️ Beta: Contacta a tu ejecutivo de cuenta de Kushki antes de habilitar esta funcionalidad.
GET /webhook/v1/transaction/receipt/{transactionReference} devuelve un PDF del comprobante de compra, codificado en Base64, con el valor de la boleta de venta y servicios.
GET /card/v1/bin/{bin} y GET /deferred/v2/bin/{bin} devuelven la metadata de la tarjeta (banco, marca, tipo de tarjeta, país emisor) para un BIN dado, y aceptan los primeros 8 o 10 dígitos.Para los comercios chilenos, la respuesta ayuda a decidir si continúas con una solicitud de token de tarjeta (cuando cardType es CREDIT) y qué opciones de cuotas ofrecer. Úsala también para mostrar el logo de la marca de la tarjeta en el checkout.
POST /rules/v1/secureValidation valida el OTP que ingresa el cliente, usando el secureId que devuelve la solicitud de token. El cliente tiene 5 minutos y 3 intentos con el mismo secureId.
Sandbox
Para simular una validación de OTP aprobada en sandbox, usa 150 para CLP. Cualquier otro valor da una validación declinada.
Incluye la cabecera Idempotency-Key para reintentar operaciones sin crear duplicados:
Regla
Detalle
Ventana de validez
24 horas: después de ese plazo, la misma llave genera una transacción nueva
Longitud máxima
56 caracteres
Unicidad
Debe ser única por tipo de transacción
Formato
UUIDv4 u otro generador con suficiente entropía
Soportada en Void a transaction y Refund a transaction (tanto para cargos únicos como para preautorizaciones y cargos de suscripción), y en las preautorizaciones de suscripción.Kushki guarda el código de estado y el cuerpo de la respuesta solo si el request original resulta exitoso. Si el request falló con un 4XX o 5XX, no se guarda registro de idempotencia y puedes reintentar con la misma llave sin problema.