<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0">
  <channel>
    <title>Cambios de la API de FITAL</title>
    <link>https://merchants.fital.xyz/docs/cambios/</link>
    <description>Cambios del contrato por fecha.</description>
    <item>
      <title>2026-11-06 · Corrección</title>
      <link>https://merchants.fital.xyz/docs/cambios/</link>
      <guid isPermaLink="false">urn:fital:cambio:c31edda17f403e49dd614092</guid>
      <pubDate>Fri, 06 Nov 2026 12:00:00 GMT</pubDate>
      <description>Un monto de entrada en cero (`0`, `0.0`, `0.00`) responde `400 invalid_request` en pagos, cotizaciones y cobros, en live y en sandbox. No abre operación ni consume cupo. Si `max_source_amount` o `destination_amount` van, también deben ser mayores que cero.</description>
    </item>
    <item>
      <title>2026-11-06 · Mejora</title>
      <link>https://merchants.fital.xyz/docs/cambios/</link>
      <guid isPermaLink="false">urn:fital:cambio:dad464b48b950e4283333332</guid>
      <pubDate>Fri, 06 Nov 2026 12:00:00 GMT</pubDate>
      <description>Los pagos tienen un tope acumulado por empresa, por día natural de México y por días corridos. Rebasarlo responde `422 limit_exceeded` con `retryable: false`. Los valores y cómo se cuenta están en [Límites](/docs/limites/#montos). `max_amount` sigue en `null`: no hay tope por pago.</description>
    </item>
    <item>
      <title>2026-11-05 · Mejora</title>
      <link>https://merchants.fital.xyz/docs/cambios/</link>
      <guid isPermaLink="false">urn:fital:cambio:962752b1f9a847bc524b1913</guid>
      <pubDate>Thu, 05 Nov 2026 12:00:00 GMT</pubDate>
      <description>`Movement` y `Receipt` traen `payment_id` y `external_ref`: el movimiento dice de qué pago de esta API sale. En webhooks, el código de estado decide: cualquier `2xx` es éxito, y FITAL cierra la conexión al recibirlo. Deduplica por el `id` del cuerpo, que va firmado, y no por `X-Fital-Event-Id`. Para recuperar eventos, pide `GET /v1/events` sin cursor y recorre hasta uno que ya procesaste. La cuenta de prueba ahora aplica las validaciones documentadas de moneda, pares de depósito, baja y estimación, y un beneficiario ajeno responde `404 not_found`.</description>
    </item>
    <item>
      <title>2026-11-05 · Mejora</title>
      <link>https://merchants.fital.xyz/docs/cambios/</link>
      <guid isPermaLink="false">urn:fital:cambio:f432b9a8243eae65b4ca3319</guid>
      <pubDate>Thu, 05 Nov 2026 12:00:00 GMT</pubDate>
      <description>El documento público declara `Event.type` y `WebhookEndpoint.status` como enumeraciones, `Event.data` con una forma por tipo, la sección `webhooks`, `Retry-After` en `409` y `503`, `413` en cada operación con cuerpo, un ejemplo por código y el significado de cada valor. `system.egress_ips.changing` se emite con `ip`, `change` y `effective_at`. En la cuenta de prueba, `POST /sandbox/v1/webhooks/trigger` manda la forma real de cada tipo, `GET /sandbox/v1/latam/countries` responde `available: false`, y los escenarios de cobro y depósito dicen su `final`. Los destinos de webhook se gestionan sólo en el panel: `v1` no publica operaciones para eso.</description>
    </item>
    <item>
      <title>2026-11-05 · Mejora</title>
      <link>https://merchants.fital.xyz/docs/cambios/</link>
      <guid isPermaLink="false">urn:fital:cambio:1a04c2f5754736bb0a8c5d55</guid>
      <pubDate>Thu, 05 Nov 2026 12:00:00 GMT</pubDate>
      <description>Nuevo `POST /v1/receiving-accounts`: abre una cuenta para recibir en `USD`, `EUR`, `BRL`, `GBP` o `COP`, si tu empresa tiene esa moneda activada. Hay una por moneda: si ya existe responde `200` con esa misma cuenta y `already_existed: true`. `MXN` responde `422`: tu CLABE ya aparece en `GET /v1/receiving-accounts`. Pide el permiso nuevo `accounts:write`, firma e `Idempotency-Key`. `GET /v1/receiving-accounts` suma `sort_code`, `pix_key`, `br_code` y `bre_b_key`, y ya devuelve el número de cuenta y el BIC de las monedas que antes llegaban vacíos.</description>
    </item>
    <item>
      <title>2026-11-05 · Mejora</title>
      <link>https://merchants.fital.xyz/docs/cambios/</link>
      <guid isPermaLink="false">urn:fital:cambio:85ba2bda6a390412b8a4fd4f</guid>
      <pubDate>Thu, 05 Nov 2026 12:00:00 GMT</pubDate>
      <description>`POST /v1/collections` acepta `method: "efectivo"`, bajo solicitud: cobros en tiendas de México, en MXN, de 20.00 a 10,000.00 por operación. La instrucción llega con `type: "REFERENCE"` y `value`, la referencia que quien paga da en la tienda. Se pide con `amount`, no con `destination_amount`, y sin `expires_at` vence a los 3 días. Se consulta en `GET /v1/collections/{id}` y avisa con `collection.paid` y `collection.expired`. En `efectivo`, `paid` dice que la tienda confirmó el pago; el abono a tu cuenta llega después. Está disponible bajo solicitud: pídelo a FITAL. Sale en `GET /v1/collection-methods` sólo cuando tu empresa lo tiene activado. El sandbox lo simula igual, con referencias ficticias.</description>
    </item>
    <item>
      <title>2026-11-05 · Nuevo</title>
      <link>https://merchants.fital.xyz/docs/cambios/</link>
      <guid isPermaLink="false">urn:fital:cambio:f70d98b3caa3dfade78deb8f</guid>
      <pubDate>Thu, 05 Nov 2026 12:00:00 GMT</pubDate>
      <description>`GET /v1/latam/countries` y `GET /v1/latam/countries/{country}/entities` dicen qué países, documentos, reglas de cuenta y bancos admite un alta `latam`. El alta acepta `account_type`, y Perú ya se puede registrar por API. `GET /v1/collection-methods` añade `payer_fields`, con lo que cada método pide de quien paga; el país de `payer` se deduce de la moneda. Son rutas y campos opcionales nuevos: las integraciones actuales siguen funcionando. Revisa la [lista de migración](/docs/migracion/).</description>
    </item>
    <item>
      <title>2026-11-05 · Corrección</title>
      <link>https://merchants.fital.xyz/docs/cambios/</link>
      <guid isPermaLink="false">urn:fital:cambio:290c4f94ae8633e7821de479</guid>
      <pubDate>Thu, 05 Nov 2026 12:00:00 GMT</pubDate>
      <description>`POST /v1/collections` aplica `payer_fields`, en producción y en la cuenta de prueba. Sin un campo `required`, o con un valor fuera de `options`, responde `400 invalid_request` y nombra el campo en `details.fields`, como `payer.email`, sin crear nada. Ese rechazo no cierra la clave, pero conserva su cuerpo: un cuerpo corregido necesita otra `Idempotency-Key`. Un cobro de prueba por SPEI pide `firstName`, `lastName` y `email`: sin `payer` antes daba `201` y ahora `400`. `GET /v1/payments/{id}` trae `failure_code` también cuando el detalle ya no se puede leer: un pago `failed` da entonces `payment_rejected`. `system.egress_ips.changing` llega una vez a cada destino, también al que se activa hasta una hora antes del cambio; uno activado en esa última hora puede no recibirlo, y el aviso sigue en `GET /v1/events`. Un pago reenviado cuyo reenvío cae sigue en `processing` hasta que FITAL lo cierre. Revisa la [lista de migración](/docs/migracion/).</description>
    </item>
    <item>
      <title>2026-11-05 · Corrección</title>
      <link>https://merchants.fital.xyz/docs/cambios/</link>
      <guid isPermaLink="false">urn:fital:cambio:33d4c0ab56f303f093610484</guid>
      <pubDate>Thu, 05 Nov 2026 12:00:00 GMT</pubDate>
      <description>Un alta `latam` con datos inválidos responde `422 invalid_beneficiary` en vez de quedar en `202 processing`. `failure_code` nunca es `null` en un pago `failed`, y todo evento `payment.*` lo trae. Un rechazo registrado responde `retryable: false`, también con `in_review`. El cuerpo tiene tope de 64 KB y más allá responde `413`. Los webhooks llevan `resource_id`. `GET /v1/collections/{id}` devuelve `instruction.type` y `expires_at`. Repetir la clave de `POST /v1/collections`, `POST /v1/deposit-addresses` o `POST /v1/beneficiaries` tras un `202` entrega el resultado en cuanto existe. En `GET /v1/movements` una fila que cambia puede repetirse y nunca se omite otra. Una `Idempotency-Key` con otro cuerpo da `422 idempotency_key_reused` también pasados 7 días. `completed_at` es `null` en un recibo que no terminó en `completed`. Las llaves de producción caducan a 180 días, con avisos a 30, 7 y 1 días. Revisa la [lista de migración](/docs/migracion/).</description>
    </item>
    <item>
      <title>2026-11-05 · Mejora</title>
      <link>https://merchants.fital.xyz/docs/cambios/</link>
      <guid isPermaLink="false">urn:fital:cambio:4ae4911111c73ccf183835a5</guid>
      <pubDate>Thu, 05 Nov 2026 12:00:00 GMT</pubDate>
      <description>`POST /v1/deposit-addresses` acepta todas las redes y tokens de [Cobertura](/docs/cobertura/#redes-y-tokens): USDC, USDT, EURC y PYUSD, ahora con `solana`, `tron`, `avalanche`, `celo`, `tempo`, `linea` y `xdc`. `stellar` no está disponible. En `solana`, `tron`, `tempo`, `linea` y `xdc` un depósito rechazado no regresa automáticamente: lo dicen la tabla y el `warning` de la dirección. EURC se acredita en EURC y suma a la fila `EUR` de `GET /v1/balances`. La respuesta trae siempre `chain` en minúsculas y `currency` en mayúsculas. La cuenta de prueba acepta los mismos pares.</description>
    </item>
    <item>
      <title>2026-11-05 · Mejora</title>
      <link>https://merchants.fital.xyz/docs/cambios/</link>
      <guid isPermaLink="false">urn:fital:cambio:9a6f5dd3fca3b27e3426df90</guid>
      <pubDate>Thu, 05 Nov 2026 12:00:00 GMT</pubDate>
      <description>Nuevo `GET /v1/wallets`: lista las wallets de tu empresa con su red y su saldo disponible, en producción y en la cuenta de prueba. Es sólo consulta: las wallets no se crean ni se modifican por API. Pide el permiso nuevo `wallets:read`, que las llaves existentes no tienen: crea una llave con ese permiso. La suma por moneda es lo que da `GET /v1/balances`, salvo redondeo al centavo.</description>
    </item>
    <item>
      <title>2026-11-04 · Mejora</title>
      <link>https://merchants.fital.xyz/docs/cambios/</link>
      <guid isPermaLink="false">urn:fital:cambio:c04094100beb5fb58db643d0</guid>
      <pubDate>Wed, 04 Nov 2026 12:00:00 GMT</pubDate>
      <description>`GET /v1/payments/{id}` añade `freshness`, con `status` (`current` o `delayed`) y `as_of`. Con `delayed` el estado es lo último que se sabe. Una cancelación confirmada responde `canceled` con `delayed` hasta que una lectura la confirme; un pago cancelado que vuelve a `processing` con `current` se reabrió de verdad. Es un campo opcional nuevo: las integraciones actuales siguen funcionando.</description>
    </item>
    <item>
      <title>2026-11-04 · Nuevo</title>
      <link>https://merchants.fital.xyz/docs/cambios/</link>
      <guid isPermaLink="false">urn:fital:cambio:0340eb13fa380da9836a86ce</guid>
      <pubDate>Wed, 04 Nov 2026 12:00:00 GMT</pubDate>
      <description>Primera versión pública del contrato `v1`: cuenta, beneficiarios, pagos, cobros, direcciones de depósito, depósitos, movimientos, recibos y eventos.</description>
    </item>
  </channel>
</rss>
