Cómo Ajustar un Pago

Cuando scheduling en los pagos, es probable que tenga la necesidad de poder ajustar los pagos.

Los casos de uso de ejemplo son:

  1. cambie la cantidad en una transacción

  2. cancelar una transacción

  3. cancelar un lote de transacciones (llamado 'Instrucción' en esta guía)

 La cancelación es la única función de ajuste disponible actualmente.
Las capacidades de ajuste adicionales aún no están disponibles.
 Esta guía asume que el manejo de ajustes de pago es parte de su Scheduled Aplicación de pagos.
Su Scheduled La solución de pagos puede ser diferente (por ejemplo, distribuida en múltiples aplicaciones).
Por favor, tenga esto en cuenta al leer esta guía.

1. Comenzando

En su aplicación inicial, necesita conectar los conectores para enviar solicitudes de ajuste a la Scheduled Aplicación de pagos. Puede referirse al Ajuste de Pago Configuración de la Aplicación de Envío documentación para incorporar la dependencia de su elección de transporte.

En su Scheduled Aplicación de pagos, usted necesita conectar los conectores para recibir solicitudes de ajuste de su aplicación iniciadora. Puede referirse al Ajuste de Pago Configuración de la Aplicación de Recepción documentación para incorporar la dependencia de su elección de transporte.

El paso final es crear un adaptador en su Scheduled Aplicación de pagos para el PaymentAdjustmentPort interfaz. Aquí es donde irá su implementación. Por ahora, puede crear una implementación de marcador de posición del PaymentAdjustmentPort, y al final de esta guía puede iniciar sus flujos dentro de la implementación del puerto.

2. Construir Flujos de Cancelación

Para manejar la cancelación de las Instrucciones y Transacciones, puede crear un flujo para cada una en MPS(uno para la cancelación de instrucciones y uno para la cancelación de transacciones).

Flujo de Cancelación de Transacciones

Los estados del camino feliz del flujo de Cancelar Transacción deben ser los siguientes:

  1. Verificación del estado de pago en el almacén de pagos: asegúrese de que la transacción exista y esté en un estado de liberación pendiente.state

  2. Ajustando la Instrucción en el Almacén de Pagos: actualice los campos en la Instrucción que contiene (por ejemplo, el número de transacciones, el monto total). Esto también debe incluir un 'Verificar el Estado del Pago en el Almacén' para asegurar que la Instrucción existe y está en un estado de liberación pendiente.state.

  3. Cancelando la Transacción en el Almacén de Pagos: marque el campo globalState de la Transacción en el Almacén como "CANCELLED".

Notará que no se han proporcionado actualizaciones a la Scheduler. Esto se debe a que nuestro Scheduled Programas de soluciones de pagos Instructions, no transacciones individuales. La publicación de la Instrucción se realizará junto con las Transacciones restantes.

El global final state el flujo debe ser 'CANCELADO' y marcado como 'Terminal’s tate.

A continuación se muestra un flujo de muestra:

CancelTransaction

Flujo de Instrucción de Cancelación

Los estados del camino feliz del flujo de Instrucción de Cancelación deben ser los siguientes:

  1. Verificación del estado de pago en el almacén de pagos: asegúrese de que la instrucción exista y esté en un estado de liberación pendiente.state

  2. Cancelando la Instrucción en el Almacén de Pagos: marque el campo globalState de la Instrucción en el Almacén como "CANCELADO".

  3. Cancelando la Instrucción en el Pago Scheduler: llame a la operación de cancelación en el Scheduler interfaz

  4. Cancelar las Transacciones contenidas en el Almacén de Pagos: marque el campo globalState de cada Transacción en el Almacén como "CANCELADO".

El global final state el flujo debe ser 'CANCELADO' y marcado como 'Terminal’s tate.

A continuación se muestra un flujo de muestra:

CancelInstruction

Enviar respuesta Camt029

Una vez que se complete el flujo de cancelación, usted puede enviar un camt. 029 mensaje de vuelta a la aplicación iniciadora. Esto se puede hacer utilizando Spring Beans proporcionado en los conectores del servidor que usted importó previamente. Hay 2 Spring Beans usaremos:

  1. PaymentAdjustmentResponseMapper: convierte la solicitud de cancelación original y un código de error opcional en un camt. 029

  2. PaymentAdjustmentResponseSender: envía el camt. 029 sobre su transporte elegido

A continuación se presenta un ejemplo de cómo podría hacerlo en un adaptador de flujo de cancelación.

import com.iconsolutions.ipf.core.shared.api.Payload;
import com.iconsolutions.ipf.payments.adjustment.server.common.PaymentAdjustmentResponseMapper;
import com.iconsolutions.ipf.payments.adjustment.server.common.PaymentAdjustmentResponseSender;
import com.iconsolutions.ipf.payments.api.model.PaymentCancellationRequest;
import com.iconsolutions.iso20022.message.definitions.cash_management.camt055.CustomerPaymentCancellationRequestV08;
import lombok.RequiredArgsConstructor;
import paymentadjustment.actions.SendCamt029Action;
import paymentadjustment.adapters.CancellationFlowExternalDomainActionPort;

import java.util.concurrent.CompletionStage;

@RequiredArgsConstructor
public class CancellationFlowExternalDomainActionAdapter implements CancellationFlowExternalDomainActionPort {

    private final PaymentAdjustmentResponseSender sender;
    private final PaymentAdjustmentResponseMapper mapper;

    @Override
    public CompletionStage<Void> execute(SendCamt029Action action) {
        var payload = new Payload<CustomerPaymentCancellationRequestV08>();
        payload.setContent(action.getCustomerPaymentCancellationRequest());
        var paymentCancellationRequest = PaymentCancellationRequest.builder()
                .payload(payload)
                .build();

        return sender.initiateResponse(
                paymentCancellationRequest,
                mapper.convertValidMessage(paymentCancellationRequest, action.getFailureReasonCode()));
    }

}

3. Construcción de Flujos de Validación

Ahora que tiene los principales flujos de Cancelación en su lugar, puede ampliar su solución para incluir validaciones. Puede extender los flujos existentes o crear nuevos flujos de validación.

Se recomienda tener la validación en un flujo separado para protegerse de flujos duplicados que afecten el mismo Pago. Un ejemplo de esto podría ser una persona que activa 'cancelar transacción' a través del Operational Dashboard, y hacen clic en el botón 'cancelar' dos veces en rápida sucesión. Otro ejemplo es cuando una solicitud al Almacén de Pagos falla, y por lo tanto, el flujo reintenta; sin embargo, ambos han terminado actualizando la Entrada de Pago en el almacén.

La razón principal de esta recomendación se debe a la persistenceID de cada flujo protegiendo contra el procesamiento múltiple. Puede utilizar este concepto para establecer el PersistenceID de cada flujo de la siguiente manera:

  1. Flujo de validación: utiliza el unitOfWorkID y requestID como el persistenceID

  2. Flujo de cancelación: utiliza solo el unitOfWorkID como el persistenceID.

Este enfoque significa que el flujo de Validación puede llevarse a cabo múltiples veces por diferentes solicitudes para un único unitOfWorkID, pero el flujo de Cancelación se lleva a cabo solo una vez para un único UnitOfWorkID.

Para asegurar que el persistenceID no sea el mismo en los flujos de Validación y Cancelación, no puede utilizar 'flow-to-flow' ya que el persistenceID se trasladará entre los flujos. Para comenzar, puede llamar al Flujo de Cancelación a través de un adaptador al final del flujo de Validación para cumplir con el requisito. Le recomendamos que considere su implementación y preferencias al abordar el tema de la protección contra el procesamiento duplicado de una cancelación de pago.

Si está separando su flujo de Validación de su flujo de Cancelación, deberá recordar enviar de vuelta una respuesta camt029 si el flujo de Validación no fue exitoso.

Validar el flujo de cancelación de transacciones/instrucciones

Existen diversas validaciones que puede realizar para asegurarse de que su Pago esté listo para ser cancelado. A continuación se presentan algunas comprobaciones de validación sugeridas.

Estas son meras sugerencias, las verificaciones que usted realice dependerán de su implementación y requisitos.

  1. Verifique el estado del pago en el almacén.

    1. Una verificación inicial de que el Pago existe en el Almacén y está en estado de pendiente de liberación.state.

  2. ¿Es demasiado tarde para cancelar?

    1. Por ejemplo, sus requisitos pueden ser que no puede cancelar un pago dentro de las 5 horas posteriores a su scheduled liberación.

    2. Puede encontrar el scheduled hora de liberación de la Transacción utilizando la operación Buscar en el Scheduler

    3. Puede configurar el CancellationTimeValidator para determinar si una solicitud de cancelación es demasiado tarde según el Documentación del Validador de Tiempo de Cancelación.

  3. (Solo se aplica al validar una Transacción) Verifique si la Transacción es parte de un Lote

    1. Esto puede ser confirmado si el Almacén contiene una entrada para la Instrucción. UnitOfWorkID

    2. Si la Transacción no forma parte de un Lote, o si usted espera que forme parte de un Lote pero no puede encontrarla en el Almacén, puede desear procesarla de manera diferente.

Consideraciones

A continuación se presenta una lista de consideraciones que usted puede o no haber tenido en cuenta durante la implementación. Estos se enumeran para incitarle a considerarlos si aún no lo ha hecho.

Dado que la cancelación debe ser siempre lo 'último' que ocurra en un Pago, Icon sugiere añadir un número arbitrariamente grande (por ejemplo, 100) al ID de secuencia anterior. Esto asegurará que la última acción sobre el Unit Of Work en ambos almacenes de datos estará la cancelación.

Esta es una sugerencia para abordar el problema, y su implementación y requisitos pueden requerir una solución diferente.

Cancelando una Instrucción cuando todas las transacciones están canceladas

Puede optar por cancelar una instrucción (lote) por completo cuando todas las transacciones presentes en la instrucción sean canceladas.

Esto se puede lograr mediante los siguientes pasos:

  1. Al cancelar una transacción, consulte el almacén de pagos para encontrar todas las entradas de pago con el mismo relatedUnitOfWorkId.

  2. Cuando las últimas entradas de pago para todas las transacciones han sido marcadas como canceladas, la instrucción puede ser marcada como cancelada.

Después de que se haya cancelado la instrucción, también vale la pena cancelar el scheduled trabajo para evitar que se obtenga triggered.