En SEPA Request-to-Pay, el plazo para responder y la fecha solicitada de pago son campos distintos
El reglamento SRTP permite pedir aceptación ahora y pago después. Dos fechas hipotéticas explican por qué la caducidad de la solicitud no identifica cuándo se pide iniciar la transferencia.
SEPA Request-to-Pay no utiliza una sola fecha para todas las acciones. El reglamento del European Payments Council distingue la expiración de la solicitud, que limita cuándo puede aceptarse o rechazarse, de la fecha y hora solicitadas para iniciar el pago. La versión 4.0 consultada está vigente desde el 5 de octubre de 2025.
El primer campo corresponde al final del periodo ofrecido para responder. Cuando se alcanza, la solicitud pierde validez dentro del esquema y el proveedor del pagador envía una respuesta negativa. El segundo indica el límite solicitado por el beneficiario para iniciar el pago. El texto combina ambos para contemplar, entre otras opciones, aceptar ahora y pagar después.
En un ejemplo inventado, una solicitud pide respuesta antes del 24 de octubre a las 18:00 e iniciación del pago antes del 28 a las 12:00. Copiar únicamente el día 28 en una lista de tareas puede dejar fuera el plazo anterior de respuesta. Las fechas no pertenecen a una factura ni a una aplicación probada por esta redacción.
Para revisar un mensaje, proponemos dos rótulos explícitos: «responder a la solicitud» e «iniciar el pago solicitado». Si la interfaz solo muestra una fecha, consulta qué campo representa antes de deducir el otro. La segunda fecha tampoco promete que el dinero estará abonado a esa hora.
El EPC define SRTP como mensajería para solicitar una iniciación de pago. El caso explica sus campos temporales y no verifica un cobro, concede una autorización o modifica una operación. La respuesta, la iniciación y la confirmación bancaria que corresponda deben conservar su significado en cada servicio.