|
Administration Guide for Oracle Self-Service E-Billing > Configuring Jobs > Payment Job Types >
Configuring a pmtPaymentRefund Job
An administrator can authorize refunds and the pmtPaymentRefund job processes the refund payment. Oracle Self-Service E-Billing supports refunds for credit card transactions that have Settled or Paid status. There are three categories of refunds:
- Cancellations. A payment can be cancelled only when a payment has a status of Scheduled. If a payment is in another state, the payment cannot be cancelled.
- Voids. If a payment has a status of Authorized, it can be voided. An authorized payment must not be cancelled without performing an authorization reversal for the authorized amounts. Voids apply only to credit cards and not checks. The authorization reversal procedure is determined through the cassette implementation.
- Refunds. A payment can be refunded if it has Settled or Paid status. It is necessary to create a new payment transaction to make the refund.
The pmtPaymentRefund job consists of the following tasks:
Configuring the Batch Refunds XML
The pmtPaymentRefund job uses XML to retrieve the refund records. You must also configure the Batch Refunds XML for payment refunds as shown in the following example text. Example XML for Batch Refunds
Process the batch refunds XML using the following format: <?xml version="1.0" encoding="UTF-8"?>
<!-- The root element can be either doc or refunds both elements are supported. doc is supported for the ddf conversion. -->
<doc><!-- refunds -->
<refund>
<payeeId>BCBS</payeeId>
<userId>John</userId>
<paymentAccountNumber>4317345689007461</paymentAccountNumber>
<payerAccoutNumber>ACC1234567890</payerAccoutNumber>
<amount>200.00</amount>
<paymentType>ccard</paymentType>
<refundType>R</refundType><!-- R for Refunds D for Deposits -->
<billingSystemTransactionNumber></billingSystemTransactionNumber>
<originalTransactionNumber>12132312</originalTransactionNumber>
<sourceSystemPaymentInitiator>CSR2</sourceSystemPaymentInitiator>
<transactionDescription>Refund Desc</transactionDescription>
<notifyRequired>Y</notifyRequired>
<flexFieldOne>xxxxxx</flexFieldOne>
<flexFieldTwo>xxxxxx</flexFieldTwo>
<flexFieldThree>xxxxxx</flexFieldThree>
<flexFieldDate>mm-dd-yyyy</flexFieldDate>
</refund>
</doc><!-- refunds-->
Table 32 describes the configuration parameters you must specify in the XML file for batch refunds.
Table 32. Parameters for Configuring the Batch Refund XML File
|
|
Payee Id |
DDN Name of the Biller. (Required) |
User Id |
The user's registration ID used to identify the user. (Required) |
Payment Account Number |
The user's credit card or checking account number where the refund must be made. (Required) |
Payer Account Number |
The account number that the user is paying for. (Mandatory field for refunds.) |
Amount |
The amount to be refunded. (Optional) If the Amount tag does not contain an amount, the job refunds the original amount of the payment.) |
Payment Type |
The refund payment mode for credit card. (Required) |
Refund Type |
Refund type: R-Refund (Required) |
Billing System Transaction Number |
The transaction number provided by Oracle Self-Service E-Billing (the payment ID). (Required) |
Original Transaction Number |
The transaction number provided to the Payment module by the authorizing gateway or clearing house. Optional field, but populating this field helps the gateway to process the refund more efficiently. (Optional) |
Source System Payment Initiator |
The ID of the refund payment initiator and is used for security. (Optional) |
Transaction Description |
The description for the refund justification. (Optional) |
Notify Required |
Whether a notification is required for the refund. Notification can be sent to the biller as well as the payer. (Optional) |
Flex Field One |
Flexible field for storing custom data. (Optional) |
Flex Field Two |
Flexible field for storing custom data. (Optional) |
Flex Field Three |
Flexible field for storing custom data. (Optional) |
Flex Field Date |
Flexible field for storing custom data. (Optional) |
About the LoadsRefundsTask
The primary purpose of the LoadsRefundsTask is to obtain the refund records through the IRefundDepot interface and schedule the eligible refunds for processing by the refund submit task. The default implementation uses an XML file to retrieve the refund records. Specify the implementation class in the job configuration. If the refund type is R (Refund) then the task checks whether the required fields are set. To identify the required fields, see Table 32. To restrict querying of all payment transactions (to balance the load), a job parameter is set so that querying is done for payments made for the last configurable number of days or months. This configuration depends on the Biller's business logic. The plug-in validates the refund according to the Biller's business logic and updates the Refund for Payment ID and Payment Type fields with one of the payments payment ID and its payment type field with the selected payment transaction for the refund. The plug-in then accepts or rejects the refund. If the plug-in accepts the refund, the updated refund record is written to the database with the status as scheduled. If the plug-in rejects the refund, the refund record is written to the database with the status as Rejected. If the mandatory parameters are not set then the refund is rejected and an entry is written to the payment_refunds table with the status Rejected. Parameters for Configuring the LoadsRefunds Task
Table 33 describes the parameters you must configure for the LoadsRefunds task.
Table 33. Parameters for Configuring the LoadsRefunds Task
|
|
Payment selection criteria for refunds |
Select the unit of time (days, weeks, or months) to use for payment refund criteria. |
Selection criteria value (Greater than 0 value) |
Enter a specific number (of days, weeks, or months specified in previous field) to use for payment refund criteria. |
Refund batch file location directory |
The input directory of the XML file. |
Refund batch file name |
The XML file name. |
Refund batch file archive location directory |
The output directory of the XML file. |
Implementation of interface IRefundDepot |
The implementation class of the IRefundDepot. |
Implementation of interface ILoadRefundPlugin |
The implementation class of the ILoadRefundPlugIn. |
Skip Refund Loader Task |
Default is N (No). If there are no batch refunds for the Biller, set this parameter to Y (Yes) to skip the task. |
About the SubmitRefundTask
The SubmitRefundTask submits all the scheduled refunds for payment. This task accesses the payment_refunds table and queries all the scheduled refunds and processes them one at a time. the SubmitRefundTask processes refund types as follows:
- Cancellations. For the SubmitRefundTask, cancellations are not scheduled; all cancellations happen online. Oracle Self-Service E-Billing cancels the payment in real time and inserts a refund record into the refund table as Processed and sets the refund type to Cancellation. The pmtPaymentRefund job never gets the opportunity to process any cancellations because a cancellation is done on payments that have been scheduled and it is cancelled immediately.
If a scheduled payment is cancelled, Oracle Self-Service E-Billing processes it. If the status of the payment is Scheduled, Oracle Self-Service E-Billing cancels it immediately and the refund status changes to Processed. A refund type of Cancellation is never scheduled, so the status changes to Processed because there is no gateway interaction. If the payment is in another state, it is processed as a void or a refund.
- Voids. Voids are a special type of cancellation, applicable to credit cards only. Voids are processed online and inserted as a void to the payment_refunds table. SubmitRefundTask uses the void records, refund for payment ID and payment type fields to obtain the original payment from the payment tables. The task checks whether the obtained payments status is in the Authorized state.
If it is in the authorized state, the task performs the final validation according to the customization and accepts or rejects the new refund payment for the void. If the plug-in rejects the new payment, the refund status updates to rejected, and is stored in the database.
If the plug-in accepts the refund and the payment id of the new payment is captured through the refund, the old payment which is being voided is cancelled and updated in the database and the new payment is scheduled for processing. The status of the refund will be updated to processed and stored in the database.
If the original payment is not in the Authorized state and the status is Processed or Settled, Oracle Self-Service E-Billing processes it as a refund.
You must only use a Void on a transaction that has not yet settled. To refund a customer's money for a settled transaction, you must submit a Refund (credit) transaction.
- Refunds. All refunds with type as Refund are processed in this category. The task checks the status of the original payment, and it must be either Processed or Settled.
If the status is Processed it implies that the payment has been sent to the gateway and a response is not yet received regarding the status. In this case, the refund process for this record is temporally halted and move to the next record.
If the status of the original payment is Settled, then Oracle Self-Service E-Billing creates a new payment transaction for the specified refund with a negative amount. The refund will only be made to the original payment account if and only if there is no payment account number specified in the refunds. If the payment account number is specified in the refund along with the payment type, then the refund is made to that account number.
If the plug-in accepts the new payment, then it schedules the new payment transaction in the payment tables and updates the status of the refund to Processed and records the new payment ID in the refund using the refund payment id field. If the plug-in rejects the payment, Oracle Self-Service E-Billing changes the refund status to Rejected.
Parameters for Configuring the SubmitRefund Task
Table 34 describes the parameters you must configure for the SubmitRefundTask.
Table 34. Parameters for Configuring the SubmitRefund Task
|
|
Implementation of Interface ISubmitRefundPlugin |
The implementation class of the ISubmitRefundPlugin |
Allow multiple refunds per payment |
Y (Yes), or N (No). The option to allow multiple refunds for a payment. |
| 
