[FranciscaOtero]

Contexto

La API pública ahora devuelve el split en las suscripciones v2 y el split + split_applied en las invoices v2, pero el SDK los descartaba.

Origen: fintoc-rails #19791.

¿Qué hay de nuevo?

• V2::Subscription#split
• V2::Invoice#split y V2::Invoice#split_applied
• Ambos quedan en nil cuando no vienen en la respuesta

Tests

• Tests unitarios (fixtures sintéticos de subscription e invoice armados desde el schema; sin cassettes nuevos)

Safety Checks

• Versión y CHANGELOG actualizados (si corresponde)

Consideraciones

Revisé el resto de cambios de las specs (main-api.json de fintoc-rails y core-api.json de pacioli) entre el 2026-10-26 y el 2026-11-02 (fintoc-rails 78e9e45 → c4590b0, pacioli 2aeaa93 → 23eb151) y ya estaban en el SDK:

• Recipients (pacioli #3994): CRUD completo en client.v2.recipients
• Account verifications en Chile (pacioli #3877): create reenvía account_type y holder_id, y los códigos de error de las respuestas 403/404 ya tienen su clase (MissingResourceError, etc.). Los nuevos valores de counterparty.account_type, institution.country y reason se exponen tal cual como strings
• split en payment intents v1 (fintoc-rails #19389)

Quedó fuera, porque solo cambia documentación o validaciones del servidor y no el contrato del SDK:

• Checkout sessions: payment_method_types: ["card"] y rango de max_amount (fintoc-rails #19637, #19392)
• Validaciones de domiciliación MX en payment methods (fintoc-rails #19143, #18914, #19459, #19475)
• Ejemplos de error 422 en payment intents v2 (mandate_limit_exceeded, merchant_volume_limit_exceeded, payment_method_inactive; ya tienen su clase) (fintoc-rails #18918, #19390)
• Refunds totales de pagos con split (fintoc-rails #19096)

Rollback

Es seguro hacer rollback, solo hay que revertir la PR.

🤖🐙 Created with Compose · View session

[FranciscaOtero]

fin review

[fin-review]

LGTM ✅

[fin-review]

LGTM ✅