Changelog

Novedades de la plataforma Tonder. Las entradas más recientes aparecen primero.

5 de noviembre de 2026

Retiros: una sola forma de crearlos

Los retiros ahora se crean de una sola forma: POST /api/v1/process/ con operation_type: "withdrawal". POST /api/v1/withdrawals/ ya no está documentado, así que si tu integración lo usa, pásate a /process/:

amount, currency, transfer_method, description, metadata y fee_model conservan su nombre.

La respuesta también cambia:

• Responde 201 en lugar de 200.
• id ahora es la transacción y withdrawal_id es el retiro. Guarda los dos y envía withdrawal_id a POST /api/v1/withdrawals/perform_action/.
• status usa los nombres legibles, como Pending en lugar de PENDING.

Consulta Retiros.

30 de octubre de 2026

Cash vouchers en Colombia (COP)

Cash vouchers ya cobra en pesos colombianos:

• La misma petición que en México y Chile, con currency: "COP" y country: "Colombia".
• Efectivo en Efecty, SuRed, MovilRed Colombia y Acciones y Valores (safetypayCash, channel: "WP"), o transferencia en línea desde 44 bancos y billeteras, entre ellos Bancolombia, Davivienda y Nequi (safetypayTransfer, channel: "OL").
• Límites por banco o red, de hasta COP 41,500,000 por transacción.
• Se activa por cuenta: pide a tu gerente de integración que active Colombia antes de cobrar.

Los bank IDs y los ejemplos de petición están en Cash vouchers › Colombia; los límites, en Límites y reglas de negocio.

29 de octubre de 2026

Retiros en Chile (CLP)

Retiros › Chile (CLP)

Envía pesos chilenos desde tu saldo a una cuenta bancaria chilena con la API Direct:

• transfer_method: "CLP_TRANSFER" con currency: "CLP", a una cuenta corriente (checking) o una cuenta vista (sight).
• Pesos enteros: amount no lleva decimales, como número o como texto ("50000").
• Un beneficiario chileno: el número de cuenta, su tipo, el id de institución del banco y el RUT del titular, validados antes de la aprobación.
• Success o Failed, con decline_code y decline_reason cuando una transferencia se rechaza o se devuelve.

Todo está en Retiros en Chile; los ids de los bancos están en Referencia bancaria.

28 de octubre de 2026

Estados de cuenta mensuales en Finanzas

Finanzas › Estados de cuenta

Finanzas, en el dashboard, tiene una nueva pestaña Statements. Elige un mes en Period para ver su estado de cuenta: el saldo inicial; los pagos, contracargos, reembolsos y anulaciones; cada comisión con su total; la reserva retenida y liberada; y las liquidaciones acreditadas a retiros. Download PDF lo exporta.

Detalles en Finanzas › Estados de cuenta.

26 de octubre de 2026

Argentina: pagos con QR, transferencias bancarias y pagos a CBU/CVU/alias

Cobra en ARS en Argentina con la API Direct, sobre los rieles inmediatos 24/7 del país:

• Pago con QR (payment_method.type: "qr"): un único QR interoperable que escanea cualquier billetera o app bancaria.
• Transferencia bancaria ("transfer"): una CVU y un alias fijos para cada cliente.
• Pagos a una CBU, CVU o alias con transfer_method: "BANK_TRANSFER", desde un saldo prefondeado.
• Los pagos con QR se pueden reembolsar en total, una sola vez.

Todo está en Argentina. Los métodos se habilitan por negocio.

Webhooks 2.0: eventos por endpoint, reintentos automáticos, firma y registro de eventos

Webhooks 2.0 se habilita por cuenta —si en Desarrolladores de tu dashboard aparece la pestaña Eventos, ya lo tienes. La sección de Webhooks ahora lo documenta como el comportamiento por defecto, y conserva el anterior donde difiere.

• Endpoints — hasta 10, cada uno suscrito solo a los eventos que elijas, con el botón Enviar prueba y un secreto de firma que se muestra una sola vez.
• Catálogo de eventos — todos los eventos, agrupados como en el dashboard: pagos y reembolsos de API Direct (Short), sesiones de checkout Hosted y SDK (Long), retiros —incluido withdrawal_Canceled, con una sola L— y endpoint.test.
• Verifica la firma — cada webhook viene firmado con Standard Webhooks (webhook-id, webhook-timestamp, webhook-signature); al rotar el secreto, el anterior sigue siendo válido 24 horas.
• Entrega y reintentos — entregado significa cualquier 2xx en menos de 10 segundos; si no, hasta 6 intentos en unas 8,5 horas, además de Reenviar evento y Reintentar todos.
• Registro de eventos — cada entrega e intento durante 60 días, también desde el detalle de una transacción o un retiro.
• API de webhooks — las mismas operaciones por API; tu contacto de Tonder te da la URL base.
• Deduplica con webhook-id. Es el mismo en todos los reintentos y reenvíos. Las cuentas sin Webhooks 2.0 siguen deduplicando con id + event_type.

20 de octubre de 2026

Retiros: la guía de integración completa

La guía de Retiros se reescribió tal como la lee quien integra, a partir de la guía para comercios del equipo de integraciones, verificada en sandbox:

• Dos vías de creación, dos identificadores. POST /process/ responde 201 con id (la transacción) y withdrawal_id (el retiro); POST /withdrawals/ responde 200 con el registro completo, donde id sí es el identificador del retiro. La aprobación, el detalle y las demás acciones toman el identificador del retiro — el equivocado responde 404 Withdrawal not found: 'Item'.
• Un retiro nuevo no avanza solo hasta que lo apruebas con POST /withdrawals/perform_action/, salvo que tu comercio tenga aprobación automática.
• Dos vocabularios de estados. /process/, GET /transactions/{id}/ y los webhooks planos usan Pending … Returned; los endpoints /withdrawals/* y el webhook extendido usan los nombres internos, PENDING … REFUNDED. La guía los mapea y te pide contemplar los dos.
• Todos los endpoints de consulta, en la guía y en la Referencia API: detalle (sin barra final; el único lugar con el motivo del fallo), listado, saldo (su forma depende de tu comercio) y movimientos de cuenta (un rango de al menos dos días).
• Los webhooks vienen en formato plano o extendido, según la configuración de tu comercio; cinco eventos, con un tercero (withdrawal_Returned) cuando los fondos vuelven. Deduplica con id + event_type.
• Un solo juego de datos de prueba en sandbox, siempre con la institución 40012, incluida una CLABE que devuelve los fondos por sí sola, en Casos de prueba — Retiros.
• Antes de salir a producción: el saldo no se valida al crear ni se reserva mientras el retiro está pendiente, el nombre del beneficiario tiene un límite práctico de 40 caracteres, el comprobante (CEP) aparece entre 4 y 30 minutos después de la liquidación, y el límite de monto lo define la institución que ejecuta la transferencia.

18 de octubre de 2026

Apple Pay: Managed, o Bring Your Own con tu Merchant ID

Apple Pay ahora viene en dos modelos, con nombres que caben en una línea:

• Managed Apple Pay — el Merchant ID y el certificado de Tonder. Envías tus dominios, alojas el archivo de verificación de Tonder, y el botón del Web SDK o Hosted Checkout 2.0 renderiza Apple Pay; sin cuenta de Apple Developer. Todas las integraciones actuales corren sobre este modelo, y su página ganó una lista de verificación previa, las reglas para servir el archivo, los rangos de IP de Apple para sitios con bloqueo geográfico y una tabla de solución de problemas por síntoma.
• Bring Your Own Apple Pay — nuevo. Tu propia cuenta de Apple Developer y tu Merchant ID: Tonder te envía una solicitud de certificado, tú creas el Payment Processing Certificate en Apple y lo devuelves, y Tonder guarda la llave. Tu sitio web o tu app iOS envía cada token de Apple Pay por la API Direct, y Tonder lo descifra bajo tu Merchant ID. Se habilita bajo solicitud con tu representante; la petición de API Direct para el token se comparte durante el onboarding.

La página de Apple Pay compara los dos modelos y conserva las tarjetas de prueba del sandbox compartidas.

13 de octubre de 2026

Web SDK: Card-on-File desde el navegador y tarjetas guardadas que requieren teléfono

Guardar tarjetas con Card-on-File desde el navegador requiere @tonder.io/web-sdk 0.1.11 o posterior. La guía del SDK Web y la referencia documentan ahora todo el flujo de tarjetas guardadas, verificado en stage:

• Solo para usuarios autenticados. El secure_token no está ligado a un cliente — session.customer sí. Constrúyelo en tu servidor a partir de la cuenta autenticada y omite las tarjetas guardadas para invitados.
• Negocios que requieren teléfono. Las tarjetas guardadas siempre pertenecen a session.customer.email; algunos negocios, configurados por Tonder, requieren además session.customer.phone (E.164). Sin él, canSaveCards() devuelve false y getCustomerCards(), enrollCard() y los pagos con tarjeta guardada lanzan SAVE_CARDS_UNAVAILABLE; una tarjeta nueva se cobra igual, pero no se guarda. El teléfono nunca reemplaza al email. Consulta Negocios que requieren teléfono para tarjetas guardadas.
• Un pago con tarjeta nueva también guarda la tarjeta cuando Card-on-File está habilitado, y vuelve de getCustomerCards() con un subscription_id — las tarjetas que lo tienen se cobran sin CVV. Muestra el texto de consentimiento en tu checkout.
• enrollCard() guarda sin cobrar y limpia los campos; subscription_id viene solo con Card-on-File.
• Un flujo recomendado de nueve pasos y los códigos de error que puede producir — SAVE_CARDS_UNAVAILABLE, SECURE_TOKEN_INVALID, CUSTOMER_OPERATION_ERROR, CUSTOMER_AUTH_TOKEN_NOT_VALID, FETCH_CARDS_ERROR, SAVE_CARD_PROCESS_ERROR — están en la referencia.

Las páginas de Hosted Checkout ahora enuncian la misma regla: el email siempre identifica al cliente, y el teléfono es un requisito adicional en las cuentas que lo necesitan — nunca un reemplazo.

Una CLABE para cada usuario

POST /api/v1/clabe-assignments da a cada uno de tus usuarios finales su propia CLABE SPEI: una llamada por usuario, idempotente por user_id (201 la primera vez, 200 con is_new: false después), y cada transferencia SPEI que reciba se acredita a tu cuenta. Vive en el servicio de depósitos — https://api.tonder.io/deposits en producción, api-stage en sandbox — con tu llave Authorization: Token habitual, solo desde tu servidor. Guía: Asigna una CLABE por usuario; esquema y playground: Depósitos.

Los endpoints de status de depósitos de Frictionless SPEI ahora usan los mismos dominios — https://api-stage.tonder.io/deposits/… y https://api.tonder.io/deposits/… — en lugar de las URLs execute-api.amazonaws.com en crudo. Las URLs anteriores siguen funcionando; las nuevas se mantienen iguales si la infraestructura cambia. Consulta Consultar el status de un depósito.

9 de octubre de 2026

Hosted Checkout: tarjetas guardadas por teléfono, fondos oscuros y dominios para embeber

Precisiones de la campaña de QA de Hosted Checkout 2.0:

• Algunas cuentas requieren además el teléfono para las tarjetas guardadas. Las tarjetas guardadas siempre pertenecen al email del cliente; Tonder puede configurar tu cuenta para requerir además customer.phone. En ese caso envíalo en cada sesión que incluya saved_cards y en las sesiones de registro de tarjeta, siempre el mismo valor E.164 — se compara exactamente como lo envías. Consulta A qué cliente pertenece una tarjeta guardada.
• Usa fondos claros. theme.background_color y theme.card_background_color no cambian los colores del texto, así que un fondo oscuro deja ilegible el resumen del pedido. Consulta Personalizar el checkout.
• Los dominios para embeber son orígenes. Registra https://shop.example.com, nunca una ruta — una entrada con ruta deja el iframe en blanco sin ningún error. Consulta Embeber el checkout.

7 de octubre de 2026

Fintoc, un segundo riel de dispersión para retiros

Los retiros ahora pueden liquidarse por Fintoc además de STP. Tonder define el riel en tu cuenta, por cada método de transferencia — SPEI y tarjeta de débito funcionan en ambos rieles — y tu petición a /process/ no cambia: no hay ningún campo para elegirlo. La única diferencia visible es el valor provider en los webhooks de retiros, ahora STP o FINTOC, así que haz matching con event_type y status en lugar de provider. Consulta Retiros.

Las cuentas de prueba en Sandbox cambian según el riel: en el riel Fintoc usa un código de institución real de Banxico de 5 dígitos, como 40012 — 97846 se rechaza. Consulta Casos de prueba — Retiros.

2 de octubre de 2026

Hosted Checkout 2.0

Hosted Checkout tiene una nueva generación. Los endpoints son los mismos — POST /checkout/v1/sessions y sus acompañantes — y las sesiones de pago nuevas reciben la página 2.0 por defecto. Prueba el demo interactivo y después lee el resumen.

• Nuevo diseño — resumen del pedido, tres plantillas (ecommerce, deposit, subscription), fuentes, formas de esquinas y contraste automático del botón. Consulta Personalizar el checkout.
• Botón e idioma — submit_type (pay, deposit, subscribe) y locale (es, en, zh), por sesión o como valor por defecto del negocio. Los valores por defecto ahora se pueden leer con GET /checkout/v1/business/config.
• Apple Pay — agrega apple_pay a payment_method_types.
• Modo embebido — carga el checkout en un iframe y dale seguimiento con eventos. Consulta Embeber el checkout.
• Guardado de tarjetas — guarda una tarjeta sin cobrar, ahora documentado en Guardar una tarjeta sin cobrar.
• Procesamiento con API Direct — los pagos pasan por API Direct y envían los webhooks estándar de Tonder. El payment_id se devuelve al crear la sesión y nunca cambia; las sesiones de API Direct también devuelven payment_flow y el direct_transaction_id más reciente.
• Payment links — un link creado en el Dashboard ahora es una sesión de Hosted Checkout, con filtros, KPIs, el pago del cliente y vista previa en vivo de la apariencia. Consulta Payment links.

Tres cosas que revisar si ya integras Hosted Checkout:

• Los webhooks de sesión no se envían. session.created, session.completed y session.expired ya no se emiten; la documentación que los describía fue corregida. Da seguimiento a una sesión con los webhooks de pago o consultando la sesión.
• GET /checkout/v1/payments/{payment_id} solo acepta el payment_id numérico. Otros ids devuelven 404 E003.
• El formato de webhook cambia cuando tu cuenta pasa a API Direct. Actualiza primero tu handler — consulta Hosted Checkout legacy, que también explica cómo quedarte en el diseño de primera generación (checkout_ui_version: v1).

Correcciones del QA de integraciones

Correcciones a páginas que no coincidían con el comportamiento real de la plataforma, encontradas al integrar con comercios:

• Los webhooks se entregan una sola vez. Una entrega fallida (4xx, 5xx o timeout) se registra, pero el evento no se reenvía, así que concilia con GET /api/v1/transactions/{id}/ cualquier periodo en que tu endpoint estuvo caído. Se eliminaron las secciones de política de reintentos y Dead Letter Queue. Consulta Entrega.
• Los headers de autenticación de webhooks, por auth_method, ahora están detallados en Configuración y gestión. Una sola URL recibe todos los métodos y operaciones.
• Los retiros requieren aprobación, a menos que tu cuenta tenga habilitada la aprobación automática, desde el Dashboard o con POST /api/v1/withdrawals/perform_action/. La respuesta devuelve un withdrawal_id, distinto de id, y ese es el que usa la aprobación. Consulta Retiros.
• Las cuentas de prueba de retiros dependen de tu riel de dispersión, y el valor de provider en los webhooks de retiros varía por cuenta. Casos de prueba — Retiros ahora muestra cómo forzar Success, Failed, Declined y Returned.
• Cómo encontrar el motivo de un rechazo en el Dashboard — está en la sección Raw data del detalle de la transacción. Consulta Transacciones.
• OXXO Pay — payment_method.type es oxxopay, en minúsculas.

25 de septiembre de 2026

Claves de institución actualizadas contra Banxico

El catálogo de claves de institución ahora coincide exactamente con la lista de participantes SPEI de Banxico — 97 instituciones. Se agregaron dieciséis participantes (Hey Banco 40167, Revolut 40170, Klar, albo, Clip, MexPago, Peibo y otros entrantes recientes), se retiraron seis claves que Banxico ya no lista (40143, 90608, 90630, 90642, 90686, 90689), se eliminaron las seis claves …2 indirectas heredadas (91802–91927) y se actualizaron cinco nombres (40128 → KAPITAL, 40138 → UALA, 90631 → TRF, 90661 → KLAR, 90706 → ARCUS FI). Si tenías alguna de las claves retiradas codificada para retiros, revísala.

97 participantes SPEIVerificado el 25 de septiembre de 2026

23 de septiembre de 2026

Validación de cuentas — sabe de quién es la CLABE antes de mover el dinero

Una nueva API independiente confirma que una CLABE es real y que pertenece a tu usuario — nombre y RFC del titular, directo del banco — antes de arriesgar un solo peso. Tonder envía un depósito de prueba de 0.01 MXN (por nuestra cuenta) y lee al titular del recibo interbancario oficial. Dos llamadas: POST /api/v1/account-verifications/ para iniciar y GET /api/v1/account-verifications/{account_number} para leer holder_name, holder_id, institution y las banderas name_match / rfc_match. Una validación por CLABE, en caché 24 horas; úsala para depósitos, retiros o ambos. Mismo header Authorization: Token que el resto de la API. Guía en Validación de cuentas; endpoints en la Referencia API.

External 3DS en la API Direct

Si autenticas al tarjetahabiente con tu propio proveedor de 3-D Secure, ahora puedes pasar el resultado a Tonder en la misma petición POST /process/ — un objeto threeDomainSecure de nivel superior con el ECI, el criptograma (cavv para Visa, ucaf + directoryServerTransactionID para Mastercard) y, cuando el ECI indica no autenticado, acceptRisk: true. Tonder cobra con él: aprobado en una sola llamada, sin reto. Envía también payment_method.card_brand, para que una inconsistencia sea un 400 claro y no un rechazo del adquirente.

Solo API Direct, y la cuenta debe habilitarse primero. Lo único que hay que hacer bien: el objeto va en el nivel superior — anidado dentro de payment_method se ignora en silencio y recibes un reto 3DS normal. Campos, reglas de ECI y errores en External 3DS.

"threeDomainSecure": {
  "eci": "02",
  "ucaf": "kCO52e75N318oAB3MPZU6EhB2Td6",
  "directoryServerTransactionID": "9e8c…"
}

21 de septiembre de 2026

Endpoint de reembolso en la Referencia API

Ya está documentado un reembolso agnóstico al procesador: POST /business/{business_id}/payments/{transaction_reference}/refunds. Envía solo el amount; Tonder resuelve el procesador a partir de la referencia de la transacción. Solo tarjetas, y solo para integraciones API Direct y Web SDK — el resto sigue reembolsando desde el dashboard. Lee la nota de "no encontrado" antes de integrar: una transacción inexistente responde HTTP 200 con un string, no un 404.

Retiros — el estado Returned

Los retiros pueden terminar en un séptimo estado, Returned: la transferencia se envió y procesó, pero el banco receptor devolvió los fondos después. Es terminal y ocurre después de Success — así que un handler que solo concilia en Success nunca ve la devolución. Trata Success, Failed, Declined, Cancelled y Returned como finales. También tiene su propio webhook, withdrawal_Returned, el tercero de ese retiro. Tabla completa en Retiros → Paso 3 y el payload en Webhooks.

Corrección a la entrada del 9 de julio: decía que REFUNDED se retiraba. No fue así — se mapea a Returned.

17 de septiembre de 2026

Apple Pay — tarjetas de prueba del sandbox

La guía de Apple Pay ya incluye las tarjetas de prueba del sandbox de Apple para las redes que Tonder procesa — Visa, Mastercard y American Express — con el vencimiento y el CVV/CVC/CID de cada una, además de la configuración de Sandbox Tester en tres pasos (cuenta de tester en App Store Connect → iniciar sesión en un dispositivo real → agregar la tarjeta manualmente en Wallet). Son las FPAN más recientes de Apple (agosto de 2025); las tarjetas de prueba habituales de Tonder no se pueden agregar a Wallet, y las de Apple funcionan solo en sandbox.

15 de septiembre de 2026

Chile — límites por método, y una corrección

Los montos mínimos y máximos de cada método chileno ya están publicados en Límites y reglas de negocio:

Corrección a la entrada del 11 de septiembre: decía que los bank IDs de transferencia en línea (Banco BCI 8296, Machpay 8416, Khipu 8488/8490/8494/8491) quedaban retirados. No es así — siguen disponibles y vuelven a estar en Cash vouchers y Cobertura. Solo se retiró la red Walmart Chile (8198). Si quitaste esos IDs por esa entrada, siguen funcionando.

11 de septiembre de 2026

Cash vouchers en Chile — Caja Vecina y BancoEstado Express

Cash vouchers vuelve a aceptar efectivo en Chile, a través de dos nuevas redes de pago:

Envía channel: "WP" con uno o ambos bank IDs. La red Walmart Chile (8198) queda retirada — si la tenías en tu código, cámbiala por los dos de arriba. La transferencia en línea (Banco BCI, Machpay, Khipu) no cambia. Ver Cash vouchers y Cobertura.

17 de agosto de 2026

Liquidaciones — ciclos, reserva revolvente y el reporte

Cuándo llega tu dinero no estaba documentado: T+1 y T+2 no aparecían en ninguna parte, y la reserva revolvente era una sola línea. Dos páginas nuevas en Gestión de pagos:

• Liquidaciones — los ciclos T+1, T+2 y batch y dónde está disponible cada uno, el calendario batch de dos veces por semana, y cómo se retiene y libera la reserva revolvente a los 90 días.
• Reporte de liquidación — cada sección y columna del reporte, más una reconciliación desde el volumen procesado hasta el monto depositado.

17 de agosto de 2026

Gestión de pagos — Manejo de contracargos

Una nueva sección de primer nivel para el lado operativo de tus pagos. Abre con una referencia de contracargos por mercado:

• Manejo de contracargos — México
• Manejo de contracargos — Chile

Cada una cubre los plazos de respuesta que publican Visa, Mastercard y American Express, qué cambia entre casos domésticos y transfronterizos, y qué se espera de ti en cada etapa. Los plazos por marca, el pre-arbitraje y el arbitraje no estaban documentados hasta ahora.

La ventana de respuesta a una disputa queda en 15 días para enviar evidencia, corregida en Transacciones para que el sitio sostenga una sola cifra.

17 de agosto de 2026

Tarjetas guardadas y Card-on-File en Hosted Checkout

Ambas ya funcionaban; ninguna estaba documentada fuera de la vía del SDK. Crear una sesión de pago ahora las cubre:

• Tarjetas guardadas — agrega saved_cards a payment_method_types y el cajero lista las tarjetas guardadas del cliente junto al formulario de tarjeta nueva. payment_method_config.saved_cards.show_save_card_checkbox agrega la casilla de opt-in.
• Card-on-File — con una conexión activa con Tonder, las tarjetas se guardan automáticamente (3DS al guardar, una suscripción por tarjeta) y los pagos siguientes se saltan el CVV. No hay nada que configurar, y tiene precedencia sobre la casilla.

saved_cards y payment_method_config también están en el spec de OpenAPI, así que el esquema de la petición en esa página los lista.

7 de agosto de 2026

Guías de migración al Web SDK + Apple Pay

Dos guías nuevas para llegar a @tonder.io/web-sdk desde donde estés hoy:

• Migrar del SDK legacy — de tonder-web-sdk v2 (InlineCheckout / LiteInlineCheckout), con el mapeo método por método y el cambio de webhooks al formato Short — la parte que hay que presupuestar.
• Migrar desde API Direct — lleva tu checkout al navegador sin cambiar tu backend: mismo /process/, mismos webhooks, misma conciliación.

Y Apple Pay estrena página como método de pago: el botón del Web SDK, el registro de dominios, la disponibilidad y los eventos.

Checkout

Licencia comercial$250.00 MXN

6 de agosto de 2026

Consulta el saldo de tus retiros por API

Ya puedes consultar el saldo disponible de tu cuenta de retiros en México con el API de Consultar saldo (GET /withdrawals/balance): revisa cuánto puedes dispersar antes de crear retiros vía POST /process/. La guía de Retiros incluye la sección de saldo con ejemplos por entorno.

Nu México cambia su clave SPEI a 40638

Por disposición de Banco de México, Nu México pasó a operar como NUBANK, S.A., Institución de Banca Múltiple y con ello cambió su clave SPEI. Te afecta si envías retiros a cuentas Nu o recibes transferencias desde ellas.

Qué actualizar:

• Dispersiones — envía 40638 en institucionContraparte.
• Abonos — tu sistema y tu conexión H2H deben reconocer 40638 en institucionOrdenante.

La clave 90638 dejó de operar el 5 de agosto de 2026 a las 18:00 h (hora CDMX). Lo que se envíe con ella se rechaza.

• Referencia bancaria — la tabla de códigos de institución.

28 de julio de 2026

Nuevo módulo de Analytics en el Dashboard

Lanzamos Analytics, una sección nueva del Dashboard que profundiza en el rendimiento de tus pagos más allá de los KPIs de Inicio. Se organiza en dos vistas:

• Aceptación y Conversión — Overall, FTD y Trusted acceptance rate, APM conversion rate, tendencia de aceptación en el tiempo, aceptación por método, rendimiento por marca de tarjeta, mejores y peores bancos emisores, y la comparación FTD vs. Trusted.
• Analítica de Depósitos — total depositado, FTDs, depositantes activos y ticket promedio, con volumen y conteo de depósitos, embudo de primer depósito y distribución por monto.

Cada vista se filtra por periodo (Hoy, 7D, 30D, 90D o un rango personalizado).

• Analytics — cada KPI, gráfica y sección explicados.

9 de julio de 2026

Nuevos estados de retiros

Los retiros ahora usan el mismo vocabulario de estados que los pagos. Si tu integración esperaba los nombres anteriores, actualízala con este mapeo:

Consulta el flujo completo en Retiros.

8 de julio de 2026

Nuevo Web SDK (@tonder.io/web-sdk)

Lanzamos el nuevo SDK Web de Tonder en npm: @tonder.io/web-sdk — un SDK de navegador en TypeScript que reemplaza las variantes Full/Lite para web con un solo paquete:

• Campos de tarjeta seguros montados en tu propia UI (createTonder → init → create('card_fields') → mount → pay).

• Tarjetas guardadas y Card-on-File: enrollCard(), getCustomerCards(), removeCustomerCard() con secure_token.

• Métodos alternativos: SPEI, OXXO Pay y bancos SafetyPay (getPaymentMethodBanks()).

• Presentación hosted/3DS por redirect o embedded (modal del SDK).

• Tipos TypeScript incluidos, errores estructurados (AppError) y respuestas alineadas con los webhooks. También disponible por CDN (window.Tonder).

• SDK Web (guía) — inicio rápido y flujos de pago.

• Referencia SDK · Web — todos los métodos, tipos y errores.

Plugin Tonder Web SDK para agentes de IA

Lanzamos tonder-ai-integrations: plugins que ayudan a los agentes de IA a integrar los SDKs de Tonder correctamente. El primer plugin es Tonder Web SDK (v0.1.7), para Claude Code, Claude Desktop, Codex CLI y Codex Desktop. Empaqueta un skill de integración por framework (HTML, React, Next.js, Angular) y un servidor MCP local (tonder-docs) con documentación versionada del Web SDK — recetas, referencia del API, errores y estados de pago.

Flujos soportados: pago con tarjeta, enrolamiento, tarjetas guardadas, métodos de pago y bancos SafetyPay. Se instala hoy desde el marketplace del repositorio de GitHub.

• MCP Integration — qué es y cómo trabaja.
• Instalación — paso a paso por host.
• Uso — prompts de ejemplo y herramientas del MCP.

10 de junio de 2026

Rediseño de la documentación

Esta documentación estrenó un rediseño completo:

• Cabecera de dos filas con búsqueda al centro y pestañas (Docs · Referencia API · Referencia SDK · Recursos · Changelog).
• Sidebar con chips de icono, migas de pan sobre cada título y tabla de contenidos renovada.
• Bloques de código estilo inset, tablas minimalistas y tarjetas para compartir (OG) con la marca Tonder.
• Diagramas nativos (flujos y secuencias) en las guías de Hosted Checkout.

8 de junio de 2026

Nuevo dashboard de Tonder

Lanzamos un dashboard rediseñado — más rápido, más claro y con analítica nativa: Home, Analytics, Fraud & Risk, Transacciones, Retiros, Finanzas, Payment Links, Developers, Webhooks y Team Members.

También en esta versión

• Cash vouchers — el método de pago en efectivo antes llamado SafetyPay ahora se llama Cash vouchers. La integración no cambia (mismo type en la API). Ver Cash vouchers.