Plataforma
Lo que cambió para quien integra, con la fecha en que salió a producción. Lo más nuevo, arriba.
Cada entrada dice de un vistazo si tienes que hacer algo: Nuevo no rompe nada de lo que ya tenías; Cambio altera algo que ya existía, así que conviene leerlo; Corrección arregla la documentación sin que la API haya cambiado.
failed trae decline: status_detail (el motivo, como INSUFFICIENT_FUNDS) y advice_action, el consejo de la red: RETRY, UPDATE_AND_RETRY, AUTHENTICATE_AND_RETRY o DO_NOT_RETRY. Viene en la respuesta del cobro, en GET /v1/payments/{id} y en el aviso payment.failed. Si el rechazo llega como error (4xx), el error trae payment_id y decline. Ver másPOST /v1/payments y las operaciones sobre un cobro ya no traen provider.response ni provider.endpoint: provider solo dice name: "processor" (y la operación, en un cobro). Lo útil de esa respuesta ya estaba en los campos del cobro: installment, parent_transaction_data y ahora decline. Un error del procesador trae details solo cuando su motivo es una frase corta; nunca su cuerpo. Ver másGET /v1/payments/{id} trae cleared_at, la fecha en que la red compensó el cobro, como ya lo hacía el listado. Ver mássucceeded y suma refunded_amount (y admite reason y comment); la metadata no vuelve intacta; los avisos dispute.created y dispute.updated llegan también al comercio; clientes pagina con cursor; los estados de una disputa y los campos de una suscripción; los mensajes de validación, que ya llegan en español; y los códigos 502, operation_not_supported_for_method, extra_items_not_supported y contact_rejected. Ver másmetadata que empiezan por lane_ o blink_ se descartan: son nombres que usa Lane. La metadata de cobros y suscripciones tampoco las muestra. En algunos cobros por PSE, Nequi, Daviplata o Bre-B anteriores a esta fecha, provider_payment_id viene vacío. Ver más2xx ya no se reintenta sin fin: se deja de intentar 3 días después de creado el evento y queda como fallida, igual que una a la que no se pudo conectar (que antes se daba por fallida al quinto intento). Desde Desarrolladores → Webhooks puedes reenviarla cuando tu endpoint esté arreglado. Ver máshttps://lane.money/auth/signup?como=plataforma. No necesita tener un comercio en Colombia: dice de qué país es y el equipo de Lane la habilita con sus condiciones. Ver mássucceeded desde la autorización: en la respuesta de la API, en las listas y en el aviso, que pasa a ser payment.succeeded. La captura la hace el procesador después y ya no genera un segundo aviso. El estado authorized y el evento payment.authorized quedan solo para una preautorización (capture.mode: MANUAL). Si tu integración esperaba payment.authorized y después payment.succeeded, ahora recibe solo el segundo: despacha con ese. Ver mássk_test_ y entrega los datos del comprador enmascarados. Se conecta en https://lane.money/mcp/cuenta o se corre en tu máquina. Ver másconvertir_monto, medios_para_monto, validar_peticion, explicar_error, explicar_evento y novedades, y el objetivo plataforma en guia_de_integracion. Ninguna toca la API ni pide llave. Ver másmerchant.approved si ya puede cobrar de verdad, merchant.rejected si no pasó. Llegan a todos sus endpoints, de prueba y reales. Ver más422 con code: payment_method_unavailable, y details dice cuáles sí tiene. Antes el cobro se creaba y el comprador encontraba el error al pagar. Ver másPOST /v1/payments, en las operaciones sobre un cobro (devolver, capturar, anular) y en POST /v1/enrollment/sessions. Un 504 con charge_unconfirmed no se reintenta: se consulta el cobro. Ver másdata.payment y no trae tu metadata (vuelve al consultar el cobro). Y un error trae error, code, a veces details, y request_id. La API no cambió. Ver másLane-On-Behalf-Of, los invita con enlaces de registro (/v1/platform/signup-links), los lista (/v1/platform/merchants) y recibe sus avisos con connected_merchant_id. Ver másline_items para mostrar el pedido, extra_items para ofrecer hasta tres productos más y available_payment_methods para limitar los medios. Ver másPOST /v1/checkout/sessions, POST /v1/payment_links y POST /v1/platform/signup-links aceptan la cabecera: la misma petición con la misma clave, en las 24 horas siguientes, responde lo mismo que la primera, con Idempotent-Replayed: true. Ver másenvironment. Para recibir los dos, registra un endpoint en cada modo. Ver másexpires_in acepta entre 60 y 31536000 segundos, y la sesión vive lo mismo que la página a la que apunta. Por defecto siguen siendo 12 horas. Ver másEsta página en markdown: /docs/novedades.md · Toda la documentación: /docs/llms-full.txt