Fichier XML CorePaymentActions

Le fichier CorePaymentActions.xml définit les actions de paiement requises pour déplacer le paiement de l'état actuel vers l'état ciblé requis.

Les actions de paiement possibles sont les suivantes : Approve, Deposit, ReverseApproval, ConsumeAmount et Error. Le fichier CorePaymentActions.xml définit chacun de ces états cibles :

TargetDNE
TargetApproved
TargetDeposited

Ce fichier se trouve dans le répertoire suivant :

workspace_dir/WC/xml/config/payments/edp/groups/default/paymentConfiguration_name
workspace_dir/wc/xml/config/payments/edp/groups/default/paymentConfiguration_name

paymentConfiguration_name est défini dans le fichier PaymentMethodConfigurations.XML

Remarque : Un seul fichier CorePaymentActions.xml doit exister pour chaque configuration de paiement nommée dans le fichier PaymentMethodConfigurations.xml.

Si vous élaborez un plug-in de paiement et que vous devez vous connecter à un système dorsal de paiement, il est recommandé de vous familiariser avec ce fichier.

Le marquage dans chacun de ces éléments définit l'action à prendre pour déplacer l'objet de paiement de son current état vers l'état target lorsque l'état actuel du paiement est l'un des états suivants : DNE (N'existe pas) APPROVED ou DEPOSITED.

L'exemple suivant d'un fichier CorePaymentActions.xml montre les comportements de base configurés pour les états cibles valides qui peuvent exister dans une configuration règles de paiement pour les actions de paiement. Pour obtenir une explication des éléments et attributs utilisés dans l'exemple, reportez-vous à la section qui suit l'exemple.

Figure 1. Exemple

<?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>

Paramètres

nom

Le nom de l'action de paiement. Les valeurs possibles sont les suivantes :

Approuver

Approuve le paiement.

ReverseApproval

Annule l'approbation de paiement.

Acompte

Verse le paiement.

Crédit

Rembourse le paiement.

ConsumeAmount

Met à jour les informations en interne dans HCL Commerce, mais n'effectue aucune action de paiement directe avec un système dorsal de paiement. Par exemple, ConsumeAmount peut être utilisé pour mettre à jour des informations sur une date d'expiration de carte de crédit. Une mise à jour est toujours effectuée si une action de paiement est définie.

Erreur

Génère une erreur.

msg: Ce paramètre est utilisé avec l'action name="Error" et contient le texte réel du message d'erreur. Un message d'erreur s'affiche dans les situations d'exception où le déplacement de l'état de paiement actuel vers l'état de paiement cible est considéré comme non valide. Le texte doit s'afficher dans la langue prise en charge par votre magasin. Le texte du message d'erreur peut être affiché dans un message de rappel, au client dans le navigateur Web, ou au personnel de support tel qu'un représentant du service clientèle.

amount

existant: Le même montant que le montant actuellement connu par le système.
delta: Différent du montant actuel.
demandé: Le même montant que le montant de paiement demandé.

cible

Spécifie l'objet de paiement cible de l'action. Par exemple, lorsque l'état actuel d'un paiement est Approuvé, que le montant de paiement en cours de traitement est inférieur à celui demandé et que l'état cible du paiement est Déposé, le montant traité représente un écart et l'objet cible doit créer un paiement supplémentaire (objet de paiement supplémentaire) pour le montant de l'écart. Les valeurs possibles pour l'attribut cible sont les suivantes :

nouveau: Un nouvel objet de paiement doit être créé et les données doivent être écrites dans la base de données.
supplémentaire: Une opération supplémentaire devrait suivre. Les données sont conservées en mémoire, mais ne sont pas écrites dans la base de données.
existant: Le montant du paiement est le même que celui actuellement prévu par le système.

L'élément TargetDeposited ne doit jamais contenir d'attribut target="additional sans être immédiatement suivi d'un attribut target="existing.

MINAMOUNT

Spécifie le montant minimum de l'action. Si le montant de la requête est inférieur au montant minimum, l'action prendra le montant minimum au lieu du montant de la requête. Vous pouvez spécifier le montant de cet élément. Néanmoins, vous pouvez également spécifier une valeur spéciale pour cet élément currency_min, cela signifie que le montant sera le montant minimum pour la devise : 1 pour le yen japonais et 0,01 pour le dollar américain.

Explication de l'exemple

Dans l'exemple illustré, la section TargetDNE contient les éléments suivants :

<CurrentDNE> Un élément vide. Un élément vide indique qu'aucune action de paiement applicable n'est nécessaire. Le passage d'un état actuel DNE à un état cible DNE n'exige pas qu'une action de paiement réelle se produise avec un système dorsal de paiement à ce stade.
<CurrentApproved> Une action d'erreur est définie. Un paiement ne doit pas passer d'un état actuel APPROVED à un état cible DNE. Un message d'erreur est généré pour noter la requête de modification non valide.
<CurrentDeposited> Une action d'erreur est définie. Un paiement ne doit pas passer d'un état actuel DEPOSITED à un état cible DNE. Un message d'erreur est généré pour noter la requête de modification non valide.

Dans l'exemple, la section TargetApproved contient :

<CurrentDNE> Si un objet de paiement n'est pas déjà créé, créez un nouvel objet de paiement et approuvez le montant demandé de la réservation de paiement.
<CurrentApproved> Si l'état actuel du paiement est APPROVÉ :
- Si le montant du paiement est inférieur au paiement demandé, mettez à jour les montants de paiement, créez un nouvel objet de paiement et approuvez la différence dans les montants de paiement.
- Si les montants sont égaux, n'effectuez aucune action de paiement, mais mettez à jour le montant du paiement pour savoir quelle part du montant du paiement est consommée.
- Si le montant du paiement est supérieur au paiement demandé, n'effectuez aucune action de paiement, mais mettez à jour le montant du paiement pour savoir quelle part du paiement est consommée.
<CurrentDeposited> Si l'état actuel du paiement est DEPOSE :
- Si le montant du paiement est inférieur au paiement demandé, mettez à jour les montants de paiement, créez un nouvel objet de paiement et approuvez la différence dans les montants de paiement.
- Si les montants sont égaux, n'effectuez aucune action de paiement, mais mettez à jour le montant du paiement pour savoir quelle part du montant du paiement est consommée.
- Si le montant du paiement est supérieur au paiement demandé, n'effectuez aucune action de paiement, mais mettez à jour le montant du paiement pour la phase commerciale afin de savoir quelle part du paiement est consommée.

Dans l'exemple, la section TargetDeposited contient les éléments suivants.

<CurrentDNE> Si l'objet de paiement n'est pas déjà créé, approuvez le montant de paiement demandé, créez un paiement supplémentaire et versez le montant demandé pour le paiement existant.
<CurrentApproved> Si l'état actuel du paiement est APPROVED :
- Si le montant du paiement est inférieur au paiement demandé, versez le montant du paiement existant. Ensuite, approuvez la différence en tant que montant de paiement supplémentaire, et versez la différence pour le paiement existant.
- Si les montants sont égaux, versez le montant existant pour le paiement existant.
- Si le montant du paiement est supérieur au paiement demandé, consommez le montant de l'approbation de paiement.
```
<AmountGreaterThanRequested>
     <Action name="ConsumeAmount"/>
</AmountGreaterThanRequested> 
```
  Dans un dépôt cumulatif, lorsque le montant approuvé est supérieur au montant du dépôt demandé, l'action effectuée est "ConsumeMount". Cette action n'effectue aucune action de paiement direct avec le système dorsal de paiement. Il met à jour le montant de paiement interne pour la phase commerciale afin de savoir quelle part du paiement est consommée.
  Les dépôts peuvent être configurés comme cumulatifs ou non cumulatifs dans le fichier CorePaymentActions.xml. Par défaut, le type de dépôt est cumulatif. Sauf si vous écrivez ou ajoutez un nouveau plug-in de paiement ou modifiez la valeur règles de paiement par défaut, vous ne devriez pas avoir besoin de modifier le type de dépôt.
  
  dépôt cumulatif
  
  Un dépôt qui n'est effectué que lorsque tout l'argent est disponible pour le dépôt. Par exemple, si un paiement est approuvé pour 100 $ (dollars américains) pour un pull et une chemise, et que des fonds sont disponibles pour capture à 60 $ (pull) dans une exécution de commande et à 40 $ (chemise) dans une exécution de commande ultérieure, les dépôts individuels de 60 $ et 40 $ ne se produisent pas individuellement. Au contraire, le système "attend" que la somme totale de 100 $ soit disponible pour le dépôt. Un dépôt cumulatif capture les fonds le plus tard possible. Les commerçants paient des frais de traitement moins élevés pour ce type de dépôt, parce qu'il minimise le volume d'activités de traitement qui se produit avec un système d'arrière-plan financier. Les dépôts cumulatifs sont généralement associés à la vente d'articles de commande bon marché, où les commerçants ont une tolérance élevée au risque en cas de non-paiement. Par défaut, le type de dépôt configuré dans le fichier CorePaymentActions.xml est cumulatif.
  
  dépôt non cumulatif
  
  Un dépôt qui capture les fonds dès que possible. Les dépôts ont lieu au fur et à mesure qu'ils se produisent, même si seulement une partie du montant total est disponible pour la capture. Lorsque plusieurs exécutions de commande sont impliquées, les montants sont déposés au fur et à mesure qu'ils se produisent et ne sont pas accumulés pour être déposés en une seule fois. Les commerçants paient généralement des frais supplémentaires pour le traitement des dépôts non cumulatifs, car de nombreuses activités de traitement des dépôts se produisent avec le système d'arrière-plan financier. Les dépôts non cumulatifs sont souvent associés à la vente d'articles de commande coûteux, où les commerçants pourraient avoir une tolérance faible au risque en cas de non-paiement.
```
 <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 les dépôts sont cumulatifs et que, pour une raison quelconque, certains dépôts approuvés n'ont pas été déposés, une activité de nettoyage peut être effectuée pour verser des montants qui auraient dû être versés, mais qui ne l'ont pas été. En savoir plus sur l'utilisation de la commande de contrôleur EDPDepositableMountProcessCmd pour procéder ainsi. Pour plus d'informations sur des commandes spécifiques, reportez-vous à la documentation de l'API.
<CurrentDeposited> Si l'état actuel du paiement est DEPOSITED :
- Si le montant du paiement est inférieur au paiement demandé, versez le montant existant du paiement existant. Ensuite, approuvez la différence en tant que montant de paiement supplémentaire, et versez la différence pour le paiement existant.
- Si les montants sont égaux, versez le montant existant pour le paiement existant.
- Si le montant du paiement est supérieur au paiement demandé, n'effectuez aucune action de paiement, mais mettez à jour le montant du paiement pour la phase commerciale afin de savoir quelle part du paiement est traitée.

Figure 2. Dépôt cumulatif. Dans cette configuration, aucune transaction financière n'aura lieu avec un système dorsal de paiement (l'action est ConsumeAmount et non pas Deposit). Au lieu de cela, le système met à jour le montant de paiement interne pour la phase commerciale afin de savoir quelle part du paiement est consommée.


<TargetDeposited>
     <CurrentApproved>
          <AmountGreaterThanRequested>
               <Action name="ConsumeAmount"/>
          </AmountGreaterThanRequested>
     <CurrentApproved>
</TargetDeposited>

Figure 3. Dépôt non cumulatif avec une action Approve et une action Deposit dans des appels séparés.. Dans cette configuration, le montant d'approbation existant est annulé. Deux approbations distinctes auront lieu et un dépôt. Aucun montant d'approbation n'expirera dans le système dorsal de paiement.


<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>

Figure 4. Dépôt non cumulatif avec une action Approve et Deposit en un seul appel. Dans cette configuration, le montant d'approbation existant est annulé. Une action Approve et Deposit se produit en même temps. Une action d'approbation supplémentaire se produira. Aucun montant d'approbation n'expire dans le système dorsal de paiement.


<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>

Les exemples Dépôt non cumulatif avec une action Approve et une action Deposit dans des appels séparés. et Dépôt non cumulatif avec une action Approve et Deposit en un seul appel affiche plusieurs actions ou transactions financières en cours. Si vous utilisez le plug-in de paiement SimpleOfflinePlugin et que vous avez configuré le fichier SimpleOfflinePlugin.xml pour conserver les transactions dans un état En attente pour une intervention manuelle, vous ne pouvez pas utiliser ces exemples car chaque action nécessitera une approbation manuelle. Vous pouvez réduire au minimum le nombre d'actions nécessitant une intervention manuelle en utilisant plutôt l'exemple 2.