OPT-PIS-001Banco y TPPreguladoincoherenciaIniciación de pagos
Confirmación de un pago por el PSU
¿Cómo confirma el PSU un pago?
Las opciones
Enforced redirect
El PSU es redirigido al banco. Tras la SCA, el PISP obtiene un access token por authorization code y lo usa para su propia confirmación.
Decoupled
El banco autentica al PSU en otro canal y llama directamente a la URL de retorno del PISP; después, el PISP confirma con su token client credentials.
- En STET 1.6.3
- Parte 1, §3.4.5.1 Casos de uso, p. 48
- Parte 1, §3.4.5.3 Enfoque ENFORCED REDIRECT, p. 49
- Parte 1, §3.4.5.4 Enfoque OAuth2 DESACOPLADO, p. 52
- Parte 1, §3.4.5.5 Tabla recapitulativa, p. 52
- OpenAPIPOST /payment-requestsPOST /payment-requests/{paymentRequestResourceId}/confirmationSupplementaryData.acceptedAuthenticationApproach
- Lado del banco
- El simple redirect solo sirve para la cancelación: para confirmar un pago en redirect, el enforced redirect es obligatorio. El banco elige entre los enfoques que propone el PISP, o responde 400 con la lista de los que soporta. Espera la confirmación del PISP antes de ejecutar la transferencia, e ignora cualquier confirmación posterior.
- Lado del TPP
- Enviar los enfoques aceptados en
acceptedAuthenticationApproachy leerappliedAuthenticationApproachen la respuesta 201. En redirect, el nonce contra la fijación de sesión es obligatorio, y la especificación recomienda cancelar el pago por fraude si su verificación falla. En decoupled, exponer una URL de retorno accesible para el banco. - Regulación
Una sola SCA basta para una iniciación cuando el PISP transmite toda la información, incluido el IBAN del deudor. Exigir dos es un obstáculo, salvo motivo de seguridad debidamente justificado (dictamen de la EBA de 2020, §24 a 26).
Textos citados
- Incoherencia de la spec
- El §3.4.2.6 dice que un token client credentials puede servir para la confirmación en «basic REDIRECT», lo que contradice el §3.4.5.3.
acceptedAuthenticationApproachse describe como una lista separada por comas, pero tiene tipo array.
La ficha tal como está almacenada
{
"id": "OPT-PIS-001",
"edition": "1.6.3",
"chooser": "both",
"title": {
"fr": "Confirmation d'un paiement par le PSU",
"en": "PSU confirmation of a payment",
"es": "Confirmación de un pago por el PSU",
"pt-br": "Confirmação de um pagamento pelo PSU"
},
"question": {
"fr": "Comment le PSU confirme-t-il un paiement ?",
"en": "How does the PSU confirm a payment?",
"es": "¿Cómo confirma el PSU un pago?",
"pt-br": "Como o PSU confirma um pagamento?"
},
"options": [
{
"label": {
"fr": "Enforced redirect",
"en": "Enforced redirect",
"es": "Enforced redirect",
"pt-br": "Enforced redirect"
},
"text": {
"fr": "Le PSU est redirigé vers la banque. Après la SCA, le PISP obtient un access token par authorization code et s'en sert pour sa propre confirmation.",
"en": "The PSU is redirected to the bank. After SCA, the PISP gets an access token through authorization code and uses it for its own confirmation.",
"es": "El PSU es redirigido al banco. Tras la SCA, el PISP obtiene un access token por authorization code y lo usa para su propia confirmación.",
"pt-br": "O PSU é redirecionado para o banco. Após a SCA, o PISP obtém um access token por authorization code e o usa para a sua própria confirmação."
}
},
{
"label": {
"fr": "Decoupled",
"en": "Decoupled",
"es": "Decoupled",
"pt-br": "Decoupled"
},
"text": {
"fr": "La banque authentifie le PSU sur un autre canal, appelle directement l'URL de retour du PISP, puis le PISP confirme avec son token client credentials.",
"en": "The bank authenticates the PSU on another channel and calls the PISP's return URL directly, then the PISP confirms with its client credentials token.",
"es": "El banco autentica al PSU en otro canal y llama directamente a la URL de retorno del PISP; después, el PISP confirma con su token client credentials.",
"pt-br": "O banco autentica o PSU em outro canal e chama diretamente a URL de retorno do PISP. Em seguida, o PISP confirma com o seu token client credentials."
}
}
],
"stet": {
"sections": [
{
"part": "framework",
"section": "3.4.5.1",
"page": 48
},
{
"part": "framework",
"section": "3.4.5.3",
"page": 49
},
{
"part": "framework",
"section": "3.4.5.4",
"page": 52
},
{
"part": "framework",
"section": "3.4.5.5",
"page": 52
}
],
"openapi": [
"POST /payment-requests",
"POST /payment-requests/{paymentRequestResourceId}/confirmation",
"SupplementaryData.acceptedAuthenticationApproach"
],
"flows": [],
"changes": [],
"remark": null
},
"aspsp": {
"fr": "Le simple redirect ne sert qu'à l'annulation : pour confirmer un paiement en redirect, l'enforced redirect est obligatoire. La banque choisit parmi les approches proposées par le PISP, ou répond 400 avec la liste de celles qu'elle supporte. Elle attend la confirmation du PISP avant d'exécuter le virement, et ignore toute confirmation suivante.",
"en": "Simple redirect is only for cancellation: to confirm a payment with redirect, enforced redirect is mandatory. The bank chooses among the approaches the PISP offers, or answers 400 with the list of those it supports. It waits for the PISP's confirmation before executing the transfer, and ignores any later confirmation.",
"es": "El simple redirect solo sirve para la cancelación: para confirmar un pago en redirect, el enforced redirect es obligatorio. El banco elige entre los enfoques que propone el PISP, o responde 400 con la lista de los que soporta. Espera la confirmación del PISP antes de ejecutar la transferencia, e ignora cualquier confirmación posterior.",
"pt-br": "O simple redirect só serve para o cancelamento: para confirmar um pagamento em redirect, o enforced redirect é obrigatório. O banco escolhe entre as abordagens propostas pelo PISP, ou responde 400 com a lista das que suporta. Ele espera a confirmação do PISP antes de executar a transferência, e ignora qualquer confirmação posterior."
},
"tpp": {
"fr": "Envoyer les approches acceptées dans `acceptedAuthenticationApproach`, lire `appliedAuthenticationApproach` dans la réponse 201. En redirect, le nonce contre la fixation de session est obligatoire, et la spec recommande d'annuler le paiement pour fraude si sa vérification échoue. En decoupled, exposer une URL de retour joignable par la banque.",
"en": "Send the accepted approaches in `acceptedAuthenticationApproach`, and read `appliedAuthenticationApproach` in the 201 response. With redirect, the nonce against session fixation is mandatory, and the spec recommends cancelling the payment for fraud if the nonce check fails. With decoupled, expose a return URL the bank can reach.",
"es": "Enviar los enfoques aceptados en `acceptedAuthenticationApproach` y leer `appliedAuthenticationApproach` en la respuesta 201. En redirect, el nonce contra la fijación de sesión es obligatorio, y la especificación recomienda cancelar el pago por fraude si su verificación falla. En decoupled, exponer una URL de retorno accesible para el banco.",
"pt-br": "Enviar as abordagens aceitas em `acceptedAuthenticationApproach` e ler `appliedAuthenticationApproach` na resposta 201. Em redirect, o nonce contra fixação de sessão é obrigatório, e a especificação recomenda cancelar o pagamento por fraude se a verificação dele falhar. Em decoupled, expor uma URL de retorno que o banco consiga acessar."
},
"regulation": {
"text": {
"fr": "Une seule SCA suffit pour une initiation quand le PISP transmet toutes les informations, IBAN du débiteur compris. En demander deux est un obstacle, sauf raison de sécurité dûment justifiée (avis EBA de 2020, §24 à 26).",
"en": "A single SCA is enough for an initiation when the PISP sends all the information, the debtor's IBAN included. Asking for two is an obstacle, unless there is a duly justified security reason (the EBA's 2020 Opinion, §24 to 26).",
"es": "Una sola SCA basta para una iniciación cuando el PISP transmite toda la información, incluido el IBAN del deudor. Exigir dos es un obstáculo, salvo motivo de seguridad debidamente justificado (dictamen de la EBA de 2020, §24 a 26).",
"pt-br": "Uma única SCA basta para uma iniciação quando o PISP transmite todas as informações, inclusive o IBAN do devedor. Exigir duas é um obstáculo, salvo razão de segurança devidamente justificada (parecer da EBA de 2020, §24 a 26)."
},
"sources": [
{
"act": "eba-opinion-2020",
"ref": "§24"
},
{
"act": "eba-opinion-2020",
"ref": "§26"
}
]
},
"note": {
"fr": "Le §3.4.2.6 dit qu'un token client credentials peut servir à la confirmation en « basic REDIRECT », ce qui contredit le §3.4.5.3. `acceptedAuthenticationApproach` est décrit comme une liste séparée par des virgules, mais typé en tableau.",
"en": "§3.4.2.6 says a client credentials token can be used for confirmation in “basic REDIRECT”, which contradicts §3.4.5.3. `acceptedAuthenticationApproach` is described as a comma-separated list, but typed as an array.",
"es": "El §3.4.2.6 dice que un token client credentials puede servir para la confirmación en «basic REDIRECT», lo que contradice el §3.4.5.3. `acceptedAuthenticationApproach` se describe como una lista separada por comas, pero tiene tipo array.",
"pt-br": "O §3.4.2.6 diz que um token client credentials pode servir para a confirmação em “basic REDIRECT”, o que contradiz o §3.4.5.3. `acceptedAuthenticationApproach` é descrito como uma lista separada por vírgulas, mas tipado como array."
},
"production": null,
"verifiedAt": "2026-10-19"
}