archivo XML CorePaymentActions

El archivo CorePaymentActions.xml define las acciones de pago necesarias para que el pago pase del estado actual al estado final necesario.

Las posibles acciones de pago son: Approve, Deposit, ReverseApproval, ConsumeAmount y Error. En el archivo CorePaymentActions.xml se define cada uno de estos estados finales:

  • TargetDNE
  • TargetApproved
  • TargetDeposited

Este archivo está ubicado en el directorio siguiente:

  • workspace_dir/WC/xml/config/payments/edp/groups/default/paymentConfiguration_name
  • HCL Commerce Developerworkspace_dir/wc/xml/config/payments/edp/groups/default/paymentConfiguration_name

El nombre_paymentConfiguration se define en el archivo PaymentMethodConfigurations.XML

Nota: Sólo debe haber un archivo CorePaymentActions.xml para cada configuración de pago indicada en el archivo PaymentMethodConfigurations.xml.

Si crea un plug-in de pago y necesita conectarse con un sistema de fondo de pago, se recomienda familiarizarse con este archivo.

La marcación dentro de cada uno de estos elementos define la acción que se debe llevar a cabo para mover el objeto de pago de su estado current al estado target cuando el estado actual del pago es uno de los siguientes: DNE (No existe), APPROVED (aprobado) o DEPOSITED (depositado).

En el siguiente ejemplo de archivo CorePaymentActions.xml, se muestran los comportamientos básicos configurados para los estados finales válidos que pueden existir en una configuración de reglas de pago para acciones de pago. Para obtener una explicación de los elementos y atributos utilizados en el ejemplo, consulte el apartado que sigue al ejemplo.

Figura 1. Ejemplo
<?xml version="1.0" encoding="UTF-8"?>
<PaymentActions xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xsi:noNamespaceSchemaLocation="com/ibm/commerce/edp/parsers/PaymentActions.xsd">
	<TargetDNE>
		<CurrentDNE></CurrentDNE>
		<CurrentApproved>
			<Action name="Error" msg="Target DNE; current Approved" />
		</CurrentApproved>
		<CurrentDeposited>
			<Action name="Error" msg="Target DNE; current Deposited" />
		</CurrentDeposited>
	</TargetDNE>
	<TargetApproved>
		<CurrentDNE>
			<Action name="Approve" amount="requested" target="new"
				minamount="currency_min" />
		</CurrentDNE>
		<CurrentApproved>
			<AmountLessThanRequested>
				<Action name="ConsumeAmount" />
				<Action name="Approve" amount="delta" target="new" />
			</AmountLessThanRequested>
			<AmountEqualsRequested>
				<Action name="ConsumeAmount" />
			</AmountEqualsRequested>
			<AmountGreaterThanRequested>
				<Action name="ConsumeAmount" />
			</AmountGreaterThanRequested>
		</CurrentApproved>
		<CurrentDeposited>
			<AmountLessThanRequested>
				<Action name="ConsumeAmount" />
				<Action name="Approve" amount="delta" target="new" />
			</AmountLessThanRequested>
			<AmountEqualsRequested>
				<Action name="ConsumeAmount" />
			</AmountEqualsRequested>
			<AmountGreaterThanRequested>
				<Action name="ConsumeAmount" />
			</AmountGreaterThanRequested>
		</CurrentDeposited>
	</TargetApproved>
	<TargetDeposited>
		<CurrentDNE>
			<Action name="Approve" amount="requested"
				target="additional" />
			<Action name="Deposit" amount="requested" target="existing" />
		</CurrentDNE>
		<CurrentApproved>
			<AmountLessThanRequested>
				<Action name="Deposit" amount="existing"
					target="existing" />
				<Action name="Approve" amount="delta"
					target="additional" />
				<Action name="Deposit" amount="delta" target="existing" />
			</AmountLessThanRequested>
			<AmountEqualsRequested>
				<Action name="Deposit" amount="existing"
					target="existing" />
			</AmountEqualsRequested>
			<AmountGreaterThanRequested>
				<Action name="ConsumeAmount" />
			</AmountGreaterThanRequested>
		</CurrentApproved>
		<CurrentDeposited>
			<AmountLessThanRequested>
				<Action name="Deposit" amount="existing"
					target="existing" />
				<Action name="Approve" amount="delta"
					target="additional" />
				<Action name="Deposit" amount="delta" target="existing" />
			</AmountLessThanRequested>
			<AmountEqualsRequested>
				<Action name="Deposit" amount="existing"
					target="existing" />
			</AmountEqualsRequested>
			<AmountGreaterThanRequested>
				<Action name="ConsumeAmount" />
			</AmountGreaterThanRequested>
		</CurrentDeposited>
	</TargetDeposited>
</PaymentActions>

Parámetros

name
Nombre de la acción de pago. Los valores posibles son:
Aprobar
Aprueba el pago.
Anular aprobación
Anula la aprobación de pago.
Depositar
Deposita el pago.
Abonar
Reembolsa el pago.
ConsumeAmount
Actualiza internamente la información en HCL Commerce pero no realiza ninguna acción de pago directo con un sistema de fondo de pago. Por ejemplo, se puede utilizar ConsumeAmount para actualizar información sobre la fecha de caducidad de una tarjeta de crédito. Siempre se lleva a cabo una actualización si se define una acción de pago.
Error
Genera un error.
msg
Este parámetro se utiliza cuando la acción es name="Error" y mantiene el texto real de mensaje de error. Se visualiza un mensaje de error en situaciones de excepción donde la transición del estado de pago actual al estado de pago final se considera no válida. El texto debe aparecer en el idioma soportado por la tienda. El texto del mensaje de error puede visualizarse en un mensaje de recordatorio, al cliente en el navegador web o para dar soporte al personal como un representante de servicio al cliente.
amount
existing
El mismo que el importe conocido actualmente por el sistema.
delta
Diferente del importe actual.
requested
El mismo que el importe de pago solicitado.
target
Especifica el objeto de pago final para la acción. Por ejemplo, cuando el estado actual de un pago es Aprobado y el importe que se procesa es menor que el solicitado y el estado final del pago es Depositado, el importe que se procesa representa un delta y el objeto final debe crear un pago adicional (objeto de pago adicional) para el importe del delta. Los valores posibles para el atributo target son:
nueva
Debe crearse un objeto de pago nuevo y los datos deben grabarse en la base de datos.
adicional
Se espera que haya a continuación una operación adicional. Los datos se mantienen en memoria pero no se graban en la base de datos.
existing
El pago tiene el mismo importe que el que espera actualmente el sistema.
El elemento TargetDeposited nunca debe contener un atributo target="additional" sin que le siga inmediatamente un atributo target="existing".
minamount
Especifica el importe mínimo para la acción. Si el importe solicitado es inferior al importe mínimo, la acción tomará el importe mínimo en lugar del importe solicitado. Puede especificar el importe para este elemento. Aunque también se puede especificar un valor especial para este elemento currency_min, esto significa que el importe será el importe mínimo para la moneda: 1 para el yen japonés y 0,01 para el dólar de EE.UU.

Explicación del ejemplo

En el ejemplo que se muestra, la sección TargetDNE contiene los elementos siguientes:

  • <CurrentDNE> Un elemento vacío. Un elemento vacío indica que es necesario llevar a cabo acciones de pago aplicables. La transición de un estado actual de DNE hasta un estado final de DNE no requiere realizar ninguna acción de pago real con ningún sistema de pago de fondo en esta fase.
  • <CurrentApproved> Se define una acción de error. Un pago no debe pasar del estado actual APPROVED (aprobado) al estado final DNE. Se genera un mensaje de error que indica la solicitud del cambio no válido.
  • <CurrentDeposited> Se define una acción de error. Un pago no debe pasar del estado actual DEPOSITED (depositado) al estado final DNE. Se genera un mensaje de error que indica la solicitud del cambio no válido.

En el ejemplo, la sección TargetApproved contiene:

  • <CurrentDNE> Si todavía no se ha creado un objeto de pago, se crea uno nuevo y aprueba el importe solicitado de la reserva de pago.
  • <CurrentApproved> Si el estado actual del pago es APPROVED (aprobado):
    • Si el importe del pago es inferior al pago solicitado, se actualizan los importes de pago y se crea un nuevo objeto de pago, y se aprueba la diferencia en los importes de pago.
    • Si los importes son iguales, no se lleva a cabo ninguna acción de pago pero sí se actualiza el importe de pago para saber la cantidad del importe de pago que se está utilizando.
    • Si el importe del pago es superior al pago solicitado, no se lleva a cabo ninguna acción de pago pero sí se actualiza el importe de pago para saber la cantidad del pago que se está utilizando.
  • <CurrentDeposited> Si el estado actual del pago es DEPOSITED (depositado):
    • Si el importe del pago es inferior al pago solicitado, se actualizan los importes de pago, se crea un nuevo objeto de pago y se aprueba la diferencia en los importes de pago.
    • Si los importes son iguales, no se lleva a cabo ninguna acción de pago pero sí se actualiza el importe de pago para saber la cantidad del importe de pago que se está utilizando.
    • Si el importe del pago es superior al pago solicitado, no se lleva a cabo ninguna acción de pago pero sí que se actualiza el importe de pago para que la fase de negocio sepa la cantidad de pago que se está utilizando.

En el ejemplo, la sección TargetDeposited contiene los siguientes elementos.

  • <CurrentDNE> Si el objeto de pago no se ha creado aún, apruebe el importe de pago solicitado, cree un pago adicional y deposite el importe solicitado para el pago existente.
  • <CurrentApproved> Si el estado actual del pago es APPROVED:
    • Si el importe del pago es inferior al pago solicitado, se deposita el importe para el pago existente. A continuación, se aprueba la diferencia como un importe de pago adicional y se deposita la diferencia para el pago existente.
    • Si los importes son iguales, se deposita el importe existente para el pago existente.
    • Si el importe del pago es superior al pago solicitado, se utiliza el importe de aprobación de pago.
      
      <AmountGreaterThanRequested>
           <Action name="ConsumeAmount"/>
      </AmountGreaterThanRequested> 
      

      En un depósito acumulativo, cuando el importe aprobado es superior al importe de depósito solicitado, la acción realizada es "ConsumeAmount." Esta acción no efectúa ninguna acción de pago directa con el sistema de fondo de pago. Actualiza internamente el importe del pago para que la fase de negocio sepa la cantidad del pago que se utiliza.

      Los depósitos se pueden configurar como acumulativos o no acumulativos en el archivo CorePaymentActions.xml. De forma predeterminada, el tipo de depósito es acumulativo. A menos que escriba o añada un nuevo plug-in de pago o bien modifique el valor predeterminado de las reglas de pago, no es necesario cambiar el tipo de depósito.

      depósito acumulativo
      Un depósito que sólo se realiza cuando está disponible todo el dinero para su depósito. Por ejemplo, si se aprueba un pago de 100 euros para un jersey y una camisa, y los fondos están disponibles para capturar a 60 euros (jersey) en una salida y 40 euros en una salida posterior, los depósitos individuales para 60 euros y 40 euros no se producirán de forma individual. Más bien, el sistema "espera" hasta que haya 100 euros disponibles para su depósito. Un depósito acumulativo captura fondos lo más tarde posible. Los comerciantes pagan cargos de proceso inferiores para este tipo de depósito porque minimiza la cantidad de actividad de proceso que se produce con un sistema financiero de fondo. Los depósitos acumulativos normalmente se asocian con la venta de artículos de bajo coste, donde los comerciante tienen una alta tolerancia de riesgo en el caso de que no se produzcan los pagos. De forma predeterminada, el tipo de depósito configurado en el archivo CorePaymentActions.xml es acumulativo.
      depósito no acumulativo
      Un depósito que captura fondos lo antes posible. Los depósitos se realizan a medida que se producen, incluso en el caso de que sólo haya disponible para su captura una parte del importe total. Cuando hay más de una salida, los importes se depositan a medida que se producen y no se acumulan para depositarse a la vez. Los comerciantes suelen pagar cargos adicionales para procesar depósitos no acumulativos porque se produce una mayor cantidad de actividad de proceso de depósitos con el sistema financiero de fondo. Los depósitos no acumulativos a menudo se asocian con la venta de artículos de pedido muy costosos, donde los comerciantes pueden tener una baja tolerancia al riesgo en el caso de que no se produzcan los pagos.
      
       <AmountGreaterThanRequested>
              <Action name="ReverseApproval"   amount="existing"      target="existing"/>
              <Action name="Approve"           amount="requested" target="additional"/>
              <Action name="Deposit"           amount="requested" target="existing"/>
              <Action name="Approve"           amount="delta"     target="additional"/>
        </AmountGreaterThanRequested>
      

      Si los depósitos son acumulativos y por alguna razón no se han depositado todos los depósitos aprobados, puede realizarse una actividad de limpieza para depositar importes que deberían haberse depositado pero que no lo están. Para obtener más información sobre cómo utilizar el mandato de controlador EDPDepositableAmountProcessCmd para hacerlo, consulte la documentación de la API para obtener más información sobre mandatos específicos.

  • <CurrentDeposited> Si el estado actual del pago es DEPOSITED (depositado):
    • Si el importe del pago es inferior al pago solicitado, se deposita el importe existente para el pago existente. A continuación, se aprueba la diferencia como un importe de pago adicional y se deposita la diferencia para el pago existente.
    • Si los importes son iguales, se deposita el importe existente para el pago existente.
    • Si el importe del pago es superior al pago solicitado, no se lleva a cabo ninguna acción de pago pero sí se actualiza el importe de pago para que la fase de negocio sepa la cantidad del pago que se está procesando.
Figura 2. Depósito acumulativo. En esta configuración, no tendrá lugar ninguna transacción financiera con un sistema de fondo de pago (la acción es ConsumeAmount y no una acción Deposit). En su lugar, el sistema actualiza internamente el importe de pago para que la fase de negocio sepa la cantidad de pago que se utiliza.

<TargetDeposited>
     <CurrentApproved>
          <AmountGreaterThanRequested>
               <Action name="ConsumeAmount"/>
          </AmountGreaterThanRequested>
     <CurrentApproved>
</TargetDeposited>
Figura 3. Depósito no acumulativo con una acción Approve y una acción Deposit en distintas llamadas.. En esta configuración, se anula el importe de aprobación existente. Se producirán dos aprobaciones individuales y un depósito. En el sistema de fondo de pago no caducará ningún importe de aprobación.

<TargetDeposited>
     <CurrentApproved>
          <AmountGreaterThanRequested>
               <Action name="ReverseApproval"   amount="existing"      target="existing"/>
               <Action name="Approve"           amount="requested" target="additional"/>
               <Action name="Deposit"           amount="requested" target="existing"/>
               <Action name="Approve"           amount="delta"     target="additional"/>
          </AmountGreaterThanRequested>
     <CurrentApproved>
</TargetDeposited>
Figura 4. Depósito no acumulativo con una acción Approval y Deposit en una llamada.. En esta configuración, se anula el importe de aprobación existente. Se produce al mismo tiempo una acción Approve y Deposit. Se producirá una acción de aprobación adicional. En el sistema de fondo de pago no caduca ningún importe de aprobación.

<TargetDeposited>
     <CurrentApproved>
          <AmountGreaterThanRequested>
               <Action name="ReverseApproval"   amount="existing"  target="existing"/>
               <Action name="ApproveAndDeposit" amount="requested" target="additional"/>
               <Action name="Approve"           amount="delta"     target="additional"/>
          </AmountGreaterThanRequested>
     <CurrentApproved>
</TargetDeposited>

En los ejemplos de la Depósito no acumulativo con una acción Approve y una acción Deposit en distintas llamadas. y la Depósito no acumulativo con una acción Approval y Deposit en una llamada. se muestra cómo se realiza más de una acción o transacción financiera. Si utiliza el plug-in de pago SimpleOfflinePlugin y tiene configurado el archivo SimpleOfflinePlugin.xml para mantener las transacciones en estado pendiente para una intervención manual, no puede utilizar estos ejemplos porque cada acción requerirá una aprobación manual. Puede minimizar el número de acciones que requieren una intervención manual utilizando en su lugar el ejemplo 2.