1. Inicio rápido
Kushki Docs
Español
  • Español
  • English
  • Inicio
  • Inicio rápido
    • Preguntas frecuentes
    • Paso a producción
    • Política de cambios importantes del API
    • Códigos de error
    • Datos de prueba
    • Últimas novedades
  • Glosario de pagos
    • Glosario de pagos
  • Pagos únicos con tarjeta (Online)
    • Network Tokens
    • Funcionalidades por modelo de negocio
    • Marcas de tarjeta soportadas
    • Pagos en un paso
      • Cargo directo (sin token)
      • Códigos de error autenticación OTP
      • ¿Cómo funcionan los pagos con tarjeta?
      • Acepta un pago con tarjeta
      • Acepta pagos únicos con OTP
      • Códigos de error pagos únicos con tarjeta
    • Pagos en dos pasos
      • Recibe pagos con autorización y captura
      • ¿Cómo funcionan los pagos únicos con autorización y captura?
    • Pagos con Webpay Plus
      • Reserva fondos con Webpay Plus
    • Pagos con Apple Pay
      • Pruebas en Sandbox Apple Pay
      • Configuración de Apple Pay
    • Devoluciones
      • Devoluciones, anulaciones y reembolsos
    • Autenticación 3DS
      • Introducción a 3DS
      • Integración 3DS API + librería kushki.js
      • Integración 3DS con librería kushki.js
      • Integración 100% API de 3DS
      • Códigos de error autenticación 3DS
  • Pagos recurrentes con tarjeta (Online)
    • Autentica tus suscripciones con 3DS
    • Apple Pay en Suscripciones
    • Suscripciones externas a Kushki
    • Acepta pagos one click con 3DS
    • Funcionalidades por modelo de negocio
    • Códigos de error en cargos recurrentes
    • Pagos calendarizados
      • Maneja tus cargos calendarizados
      • Crea un cargo recurrente
      • ¿Cómo funcionan los cargos recurrentes con tarjeta?
    • Pagos calendarizados con Webpay OneClick
      • Reserva fondos en recurrencias con Webpay OneClick
      • Recurrencias con Webpay OneClick
    • Pagos OneClick con Webpay OneClick
      • Pagos one click con Webpay OneClick
      • Reserva fondos en pagos one click con Webpay OneClick
    • Pagos OneClick
      • ¿Cómo funcionan los pagos OneClick con autorización y captura?
      • Recibe pagos OneClick con autorización y captura
      • Genera pagos one click
  • Pagos con tarjeta presente
    • Acepta pagos con tarjeta presente
    • Datos de prueba
    • Webhooks para tarjeta presente
    • Raw card-present API
      • Script de ejemplo para cifrar información
      • Acepta pagos
      • Intercambio de claves criptográficas
      • Preguntas frecuentes
      • Códigos de error para transacciones con tarjeta presente
    • Transacciones
      • Anula un pago
      • Transacciones
    • Kushki One
      • Autenticación y Cifrado de Requests
      • Realiza cobros con Kushki One
      • Formato de montos en Kushki ONE
      • Impresión en terminal SmartPOS
      • Catálogo Unificado de Errores — Kushki ONE Connect
      • Servicios asíncronos y webhooks
    • Kushki One App de Pagos
      • Procesa un cobro
      • Devoluciones y PreAuth & Capture
      • Pago Dividido en la terminal
      • Configuración del terminal
      • Consulta tus transacciones
  • Pagos con transferencias
    • Recibe transferencias bancarias
    • Consulta el estado de una transacción
    • Bancos y detalles de operación para pagos con transferencia bancaria
  • Pagos en efectivo
    • Acepta un pago en efectivo
    • Puntos de recaudo
    • Códigos de error para transacciones declinadas en efectivo
  • Dispersión de dinero
    • Transferencia bancaria
      • ¿Cómo funciona la dispersión por transferencia bancaria?
      • Códigos de error para dispersiones por transferencia
      • Dispersa a cuentas bancarias
  • Plugins
    • Shopify
      • Shopify
      • Operación del Plugin
    • Vtex
      • Guía de integración VTEX
  • Links de pago
    • Smartlinks
  • Formularios y botones de pago
    • Introducción
    • Kajita
      • Kajitas de pago
      • ¿Cómo funciona?
    • Botón de pago
      • Genera un botón de pago
      • ¿Cómo funciona el botón de pago?
  • Administración de sucursales
    • ¿Cómo realizar el onboarding de subcomercios vía API?
  • Notificaciones
    • Buenas prácticas
    • Consulta tus webhooks
    • Webhooks para pagos únicos
      • Webhook para pagos únicos con tarjeta
      • Webhook para pagos únicos con transferencia bancaria
      • Webhook para pagos únicos con efectivo
      • Webhook para pagos con Webpay Plus
    • Webhooks para pagos recurrentes
      • Webhook para pagos recurrentes con tarjeta
      • Webhook para pagos recurrentes con Webpay OneClick
    • Webhooks para dispersiones
      • Webhook para dispersión de dinero con transferencia
    • Webhooks para botón de pagos
      • Webhooks con Botón de pago
    • Webhooks para smartlinks
      • Webhooks con Smartlinks
    • Webhooks para devoluciones
      • Webhook para devoluciones
      • Webhook para contracargos
HomeMexico 🇲🇽Ecuador 🇪🇨Chile 🇨🇱
Colombia 🇨🇴Peru 🇵🇪
HomeMexico 🇲🇽Ecuador 🇪🇨Chile 🇨🇱
Colombia 🇨🇴Peru 🇵🇪
Status
Soporte / Support
Español
  • Español
  • English
  1. Inicio rápido

Política de cambios importantes del API

A medida que nuestra API evoluciona, se pueden producir cambios importantes o "breaking changes" que pueden impactar a tu integración.
Cada día existen actualizaciones de las aplicaciones que utilizamos en nuestros dispositivos móviles y computadoras. Y nuestro código no está exento de estas actualizaciones. Ya sea para corregir un error o para actualizar una funcionalidad, el versionamiento nos permite ofrecer nuevas funcionalidades y mejoras sin afectar las integraciones anteriores.
Cuando hablamos de aplicaciones móviles o de escritorio es posible lanzar nuevas versiones y parches con cambios menores, medianos y grandes. No obstante, en el caso del API no es posible ofrecer múltiples versiones simultaneas y mantenerlas indefinidamente para todos sus usuarios. Con base en este contexto, se establece el concepto de un cambio importante breaking change.

Breaking changes#

Un cambio importante o breaking change, es un cambio que puede requerir que realices cambios en tu aplicación para evitar interrupciones en tu integración.
Estos tipos de cambios se notificarán con antelación a tu comercio para que pueda realizar cualquier actualización requerida con tiempo y que no exista interferencias en el servicio.
Heads up
Si nos encontramos con algún error de seguridad o un bug que podría afectar de manera importante al correcto funcionamiento de nuestro producto realizaremos los cambios a la mayor brevedad posible, dentro del acuerdo de nivel de servicio.
Comunicaremos este tipo de cambios con una antelación de al menos 4 meses para que realices actualizaciones necesarias antes de que saquemos una nueva versión a producción.
Estos cambios los podemos catalogar dentro de los siguientes:
Cambios a permisos existentes
Remover un parámetro, campo de respuesta o de petición previamente permitido.
Agregar un nuevo parámetro o campo de petición que sea requerido y que no tendrá valores por defecto. Esto podría cambiar la interacción al llamar a una función ya que al no poseer el numero de campos necesarios en la petición no obtendremos respuesta o tendremos un error como respuesta
Cambios a la funcionalidad final de un endpoint
Agregar una nueva validación
Remover o renombrar un endpoint, campo o valor enum
Cambiar el tipo de un campo
Cambiar el formato del URL en la definición del HTTP
Cambiar a un campo opcional a que sea requerido en la petición

Non-breaking changes#

En contraste, los non-breaking changes son cambios a los cuales te podrás adaptar a tu discresión y ritmo sin tener intermitencias en tu integración. En la mayoría de los casos estos se presentan sin previa notificación. Asegúrate que tu aplicación o integración esta diseñada para manejar este tipo de cambios.
En términos generales si realizamos un cambio catalogado como "non breaking", el servicio o producto actual seguirá trabajando normalmente sin la necesidad de realizar actualizaciones en la integración.
Estos son los cambios que podríamos realizar sin considerar que podrían afectar la integración:
Agregar un nuevo endpoint
Agregar un nuevo método a un endpoint existente
Agregar nuevos campos en los siguientes escenarios:
Nuevos campos en respuestas
Nuevo campo de petición o parámetros opcionales
Nuevo campo de petición requerido que tendrá valores por defecto
Agregar un nuevo valor devuelto por un campo de texto existente
Cambios en el orden que son retornados los campos de respuesta
Agregar un header de petición opcional
Remover campos redundantes del header
Cambios a la longitud de la información devuelta por un campo
Cambios del tamaño promedio de la respuesta
Cambios a los mensajes de error. (Recomendamos parsear los códigos de respuesta o error v/s parsear el mensaje de error directamente en tu integración)
Cambios en los códigos de respuesta o de error pasando de un valor incorrecto a uno correcto
Añadir un nuevo valor a una enumeración o enum
Modificado en 2026-09-23 15:08:04
Anterior
Paso a producción
Siguiente
Códigos de error
Built with