Seguridad y pruebas de pagos

Controles incluidos

• Credencial de alta entropía solo server-to-server y permiso separado de pagos.
• Intención durable antes de cualquier inicio externo.
• Perfil, beneficiario, concepto, importe e institución fijados y validados por el servidor.
• Estado sensible cifrado; token de widget ligado a empresa, intención, caducidad y origen, conservado solo como hash.
• Identificadores de intento deterministas y fencing para impedir una reiniciación automática tras un resultado ambiguo.
• Callback dedicado, consumo único, control optimista de versión y lease.
• Auditoría redactada: nunca incluye credenciales, IBAN completo, IP, callbacks, respuestas completas ni estado opaco.
• Destinos y redirecciones permitidos de forma explícita, con HTTPS, tiempos máximos y respuestas acotadas.
• Mensajería del widget con origen exacto, validación de event.source y esquema versionado.

Integrar el sandbox

Solicite a Wealth Reader:

1. una credencial privada autorizada para pagos y para el perfil requerido;
2. el origen HTTPS exacto que alojará el widget;
3. los límites de importe y frecuencia acordados;
4. acceso al modo sandbox, que no mueve dinero.

Consulte siempre profile-institutions; en sandbox devolverá únicamente una institución simulada. Cree la intención con expected_mode: "mock" y compruebe que la attestation de la respuesta también indica mock antes de entregar el token al navegador.

Pruebe al menos:

• repetición de creación con la misma clave y conflicto con otro cuerpo;
• institución o modo alterados;
• token vencido y origen no permitido;
• popup bloqueado y retorno SCA;
• estado intermedio pendiente, conciliación y cierre del widget;
• confirmación únicamente al recibir payment_status: settled.

Solicitar activación real

Antes de una prueba con dinero, confirme con Wealth Reader:

• que la institución aparece en la preconsulta para su credencial;
• que el perfil y su versión están aprobados;
• que el origen, callback y flujo SCA fueron validados de extremo a extremo;
• que existen límites de importe, frecuencia, conciliación y desactivación de emergencia;
• que hay un responsable humano autorizado para la prueba mínima.

La cuenta de origen puede ser necesaria para alguna institución y, en ese caso, la solicita el widget durante la autorización. La dirección de red del usuario se deriva en la frontera controlada de la API; el cliente no debe enviarla. Ni ese dato ni el IBAN deudor se exponen en los eventos.

La secuencia con curl prepara y consulta la intención, pero no completa la autenticación bancaria. El usuario debe continuar en el navegador o aplicación bancaria.

La activación del perfil requiere tres controles de despliegue independientes y exactos: WR_PAYMENTS_CRUZ_ROJA_PROFILE_ENABLED=1, WR_PAYMENTS_CRUZ_ROJA_PROFILE_VERSION=2026-09-04 y la empresa de la credencial incluida en WR_PAYMENTS_CRUZ_ROJA_COMPANY_IDS. Estos valores no sustituyen el permiso de pagos ni habilitan por sí solos una institución real.

El contrato publicado actualmente marca psuIp como no utilizado, pero pruebas históricas del conector lo exigieron. Wealth Reader mantiene la activación bloqueada hasta verificar en el despliegue objetivo, mediante una prueba de opciones y de extremo a extremo aprobada, tanto el campo exacto como la política del proxy de confianza. No debe activarse usando cabeceras reenviadas arbitrarias ni suponiendo que la declaración publicada refleja el comportamiento histórico.

La resolución DNS privada y la terminación TLS hacia el servicio interno dependen de cada despliegue: este SDK no presume que existan ni que sean alcanzables. Deben verificarse desde el runtime de la API antes de habilitar salida o aceptar nuevas intenciones.

Qué no debe hacerse

• Enviar la API key, el beneficiario completo o datos internos al navegador.
• Inventar una institución no devuelta por la preconsulta.
• Repetir automáticamente un inicio ambiguo.
• Registrar IBAN, dirección de red, callback o respuesta bancaria completa.
• Interpretar el fin de la interacción como liquidación.
• Reutilizar rutas, tokens o callbacks de agregación bancaria.