Financial transactions
A financial transaction is either a single individual payment or a credit transaction. A payment financial transaction corresponds to a payment action in the Payment rules engine and a credit financial transaction corresponds to a refund action. Every time the Payment rules engine decides the payment or refund action that needs to be run, the corresponding financial transaction is then run in the Payments Plug-in Controller with the Payments Plug-in.
The Payments Plug-in Controller supports the following transaction types:
- approve
- deposit
- approveAndDeposit
- credit
- reverseApproval
- reverseDeposit
- reverseCredit
Depending on the transaction type, the following are different attributes
of the financial transaction:
- response code
- The response code is a representation of a financial transaction result and is back-end system specific. The response code is used by the back-end system to indicate whether the financial transaction was successful. For example, the response code might indicate that a credit card authorization failed. If your financial transaction has successfully run, set the response code to 0.
- reason code
- The reason code is a representation of an error condition and is back-end system specific. The back-end system uses the reason code to indicate why a financial transaction has failed. For example, it might indicate that a credit card has expired. When the response code alone cannot determine what error has occurred in a financial transaction, the reason code can be used to determine the error. The response code and the reason code can also be seen as primary and secondary error codes. These codes are used in problem determination whenever the standard plug-in mechanisms do not suffice.
- reference number
- The reference number is an identifier generated by the payments back-end system during the processing of financial transactions. Back-end systems need reference numbers for processing subsequent and related financial transactions. For example, a deposit transaction requires the reference number of a previous approve transaction. In this case, the reference number is the authorization code returned by the back-end system during the approve transaction.
- tracking ID
- The tracking ID is an optional attribute used by the payments plug-in to identify, on behalf of the merchant, a financial transaction in the payment back-end system. The tracking ID is set by the plug-in during the processing of financial transactions. The plug-in generates this ID to be unique in the plug-in and in the back-end system realm. Although the tracking ID is an optional attribute, it is sometimes the only way to track a financial transaction in the back-end system if an error occurs. For example, if the connection is lost during a financial transaction and the plug-in cannot determine if the back-end system has processed the transaction, the tracking ID can be used to query the back-end system once connectivity is re-established. If the tracking ID is known by the back-end system, then the transaction has reached the back-end system. If the tracking ID is unknown, then the transaction needs to be run again. While the tracking ID is used to identify a financial transaction from the plug-in perspective, the reference number is used to identify a financial transaction from the payment back-end system perspective. The tracking ID is the first identifier of the financial transaction to exist. Once the reference number is obtained from the back-end system, the plug-in no longer need the tracking ID since the reference number is then known by both the plug-in and the payment back-end system. The Payments Plug-in Controller uses the PPCPAYTRAN table to record the basic information of the financial transaction. The extended data of the financial transaction is stored in the PPCEXTDATA table. The PPCPAYTRAN_ID is the ID of the financial transaction with which the extended data is associated.