1. Inicio rápido
Kushki Docs
Español
  • Español
  • English
  • Inicio
  • Inicio rápido
    • Últimas novedades
    • Preguntas frecuentes
    • Paso a producción
    • Política de cambios importantes del API
    • Datos de prueba
    • Códigos de error
  • Glosario de pagos
    • Glosario de pagos
  • Pagos únicos con tarjeta (Online)
    • Network Tokens
    • Marcas de tarjeta soportadas
    • Funcionalidades por modelo de negocio
    • Guía de integración Comisiones a terceros
    • ¿Cómo funcionan las Comisiones a terceros?
    • Pagos en un paso
      • Acepta un pago con tarjeta
      • Cargo directo (sin token)
      • ¿Cómo funcionan los pagos con tarjeta?
      • Acepta pagos únicos con OTP
      • Códigos de error autenticación 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?
    • Devoluciones
      • Devoluciones, anulaciones y reembolsos
    • Autenticación 3DS
      • Integración 3DS API + librería kushki.js
      • Introducción a 3DS
      • Integración 100% API de 3DS
      • Integración 3DS con librería kushki.js
      • Códigos de error autenticación 3DS
    • Pagos con Apple Pay
      • Configuración de Apple Pay
      • Pruebas en Sandbox Apple Pay
  • 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
      • ¿Cómo funcionan los cargos recurrentes con tarjeta?
      • Maneja tus cargos calendarizados
      • Crea un cargo recurrente
    • Pagos OneClick
      • Genera pagos one click
      • Recibe pagos OneClick con autorización y captura
      • ¿Cómo funcionan los pagos OneClick con autorización y captura?
  • Pagos con tarjeta presente
    • Acepta pagos con tarjeta presente
    • Datos de prueba
    • Webhooks para tarjeta presente
    • Cloud Terminal API
      • Acepta pagos
      • Anula una solicitud de pago
      • Consulta el estado de una petición de cobro
      • ¿Cómo imprimir un ticket personalizado?
    • App-to-app
      • Acepta pagos
    • Transacciones
      • Anula un pago
      • Transacciones
    • Terminal SDK
      • Acepta pagos
    • 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
    • Raw card-present API
      • Acepta pagos
      • Script de ejemplo para cifrar información
      • Intercambio de claves criptográficas
      • Preguntas frecuentes
      • Códigos de error para transacciones con tarjeta presente
    • Kushki One App de Pagos
      • Devoluciones y PreAuth & Capture
      • Procesa un cobro
      • Pago Dividido en la terminal
      • Consulta tus transacciones
      • Configuración del terminal
  • Pagos con transferencias
    • Bancos y detalles de operación para pagos con transferencia bancaria
    • Recibe transferencias bancarias
    • Consulta el estado de una transacción
  • Dispersión de dinero
    • Transferencia bancaria
      • Dispersa a cuentas bancarias
      • Códigos de error para dispersiones por transferencia
  • Plugins
    • Shopify
      • Operación del Plugin
    • Vtex
      • Guía de integración VTEX
  • Links de pago
    • Smartlinks
  • Formularios y botones de pago
    • Kajita
      • Kajitas de pago
      • ¿Cómo funciona?
    • Botón de pago
      • ¿Cómo funciona el botón de pago?
      • Genera un 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
    • 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 pagos recurrentes
      • Webhook para pagos recurrentes con tarjeta
    • 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-21 16:14:43
Anterior
Paso a producción
Siguiente
Datos de prueba
Built with