Paso 7 - Añadir códigos de razón
Introducción al paso 7
En este paso añadirás un Mecanismo de Liquidación y Compensación (CSM) e introducirás dos conceptos nuevos:
-
Una Reason Code Library (biblioteca de códigos de razón)
-
Una Non-Completing Response (respuesta no completante)
En este escenario, el pago se envía como un Pacs.008 a un esquema que proporciona un acuse técnico (ack) o rechazo técnico (nack).
Si el CSM proporciona un nack, también aportará un código de razón propio. En este escenario será uno de los siguientes códigos:
-
REJ1 - Sender not recognised
-
REJ2 - Syntax Error
Si el agente del CSM proporciona un ack, entonces el flujo de pago espera una confirmación de que el esquema ha completado la validación de la instrucción.
El CSM enviará entonces un Pacs.002 con un 'TransactionStatus' que contendrá 'ACCP' (Accepted Customer Profile) o 'RJCT' (Rejected).
Si el CSM ha rechazado el pago en esta fase, proporcionará un 'StatusReasonCode' ISO.
El orden de las respuestas rechazadas del CSM no está garantizado: el rechazo de negocio podría recibirse antes que el rechazo técnico.
Añadir un nuevo dominio externo
Como en pasos anteriores, necesitas añadir otro dominio externo; esta vez para representar al CSM.
Empecemos creando uno y construyendo la respuesta técnica del CSM. El código de respuesta será 'AcceptOrReject', pero detente en 'Reason Codes', como sigue:
Crear una biblioteca de códigos de razón
Ahora puedes crear una biblioteca con los códigos de razón que el CSM usa para la respuesta técnica:
-
Haz clic derecho en el modelo en el menú izquierdo
-
Selecciona New > v2Flo > Reason Code Library
Una vez creada la biblioteca de códigos de razón, puedes poblarla con los códigos de razón del escenario:
Ahora puedes asignar el conjunto de códigos de razón que has creado al 'Payment Request'. Ya que estás ahí, desmarca la casilla 'Completing': el flujo de pago necesita esperar una segunda respuesta antes de poder continuar al siguiente paso.
Completar la configuración del Payment Request
Terminemos el 'Payment Request'. Recuerda que el CSM envía dos respuestas: primero una respuesta técnica y luego una respuesta de negocio (el resultado de la validación de la instrucción).
En la celda 'Responses', coloca el cursor debajo de 'Completing', pulsa Return y se creará una nueva respuesta vacía.
Complétala hasta la sección Response Code:
En el paso anterior creaste una biblioteca de códigos de razón, incluso cuando solo había dos posibles resultados. Esta vez, usarás simplemente los códigos de respuesta 'AcceptOrReject'. Los desarrolladores, en el conector entre el CSM y el Payment Service, convertirán los códigos de respuesta del mensaje Pacs.002; en este caso, ACCP a Accept y RJCT a Reject.
Coloca el cursor en la sección 'Response Code' y pulsa Ctrl+Space para escoger 'AcceptOrReject'.
Después, coloca el cursor en la sección 'Reason Code' y pulsa Ctrl+Space. Verás que los ISO Reason Codes son un conjunto predefinido de códigos de razón en Flow Designer, así que puedes seleccionarlos.
Esta vez 'Completing' es true, puesto que no se esperan más respuestas del CSM tras esta.
Cuando el CSM proporcione la respuesta de validación de negocio, será en forma de Pacs.002, así que asegúrate de añadir 'Payment Status Report' como business data en esas respuestas.
La petición debería verse ahora así:
Actualizar el flujo
Ahora puedes actualizar el flujo para encajar todas las piezas.
State Definitions
Primero, añadamos el nuevo estado 'Clearing and Settling' mientras el pago está siendo procesado por el CSM.
Event Definitions
Ahora añadamos cuatro eventos nuevos para el CSM. Tienes una validación técnica (aceptada y fallida) y una validación de negocio (aprobada y fallida). Cuando el CSM proporciona la respuesta de validación de negocio, será en forma de Pacs.002, así que asegúrate de añadir 'Payment Status Report' como business data para estos dos eventos.
Input Behaviour
Ahora que tienes estados, eventos, peticiones y respuestas definidos, puedes actualizar el input behaviour con las cuatro nuevas respuestas posibles a la payment request.
Event Behaviour
Y ahora puedes actualizar el event behaviour como sigue:
-
Añade el nuevo estado 'Clearing and Settling' y los cuatro eventos nuevos al event behaviour.
-
Cambia el 'Move to State' para 'Verifying Debtor Account' de 'Complete' al nuevo estado 'Clearing and Settling' y elimina la acción de crear una notificación.
-
Añade una nueva acción de 'Payment Request' para cuando la verificación de cuenta deudora haya pasado. Esto asegurará que se envía la petición al CSM para que puedas recibir una de las nuevas respuestas y el flujo pueda continuar.
-
Mueve el 'Send Notification' al lugar correcto: envías una notificación a la iniciación del pago cuando el pago ha sido procesado; ahora esto ocurre cuando se produzcan los eventos 'CSM Business Passed', 'CSM Technically Rejected' y 'CSM Business Rejected'.
Usemos otra característica del event behaviour para cubrir el hecho de que la respuesta de rechazo de negocio podría llegar antes que la de rechazo técnico.
En este escenario puedes usar 'On Any' (en lugar de 'On').
-
Elimina la fila 4
-
En la última fila cambia la columna 'When' de 'On' a 'On any of'
-
En la última fila añade el evento 'CSM Technically Failed'
Ahora has actualizado el flujo para que, si se recibe cualquiera de las respuestas de fallo de negocio o fallo técnico, el estado se mueva inmediatamente a rejected.
