La respuesta directa
Banks/acquirers son buenos en authorization, acquiring, installments, settlement y reporting. Direct use es eficiente si applications consumen esto sin duplicar operating logic. El problema surge cuando cada channel aprende cada API, status y error model.
Cuándo basta el enfoque actual
Usa direct con una o dos integrations estables, sin unified policy y reconciliation sencilla. Mantiene path corto a provider features.
Dónde empieza la presión
Con más providers se repiten rules, error normalization, retry y reconciliation. Onboarding se vuelve programa cross-product en vez de change de infrastructure.
Qué cambia con una capa de infraestructura
Shared layer centraliza adapters y expone stable business contract. Common identity, status y evidence reducen implementación repetida, manteniendo extensions especializadas cuando hacen falta.
El trade-off
Direct access puede abrir features más rápido. Platform puede ir detrás o necesitar extension points. No fuerces useful capabilities al lowest-common-denominator.
Cómo decidir
Cuenta cuántas veces se implementan eligibility, installments, refunds, errors, callbacks y reconciliation. Si una vez, direct es eficiente; si repetido, shared connectivity puede reducir surface.
Cuándo encaja Zopio
Zopio encaja cuando banks siguen siendo execution providers pero applications necesitan common connectivity/transaction layer.
Un siguiente paso práctico
Inventaría provider-specific code y separa lo genuinamente específico de repeated infrastructure. Comparte lo repetido; conserva lo especializado.
Direct bank tools pueden ser la solución correcta.
Shared layer vale por eliminar repetición.
No sacrifiques capabilities por pureza de abstraction.