FAR680
creates the EXPORT file and FAR681 IMPORTS the response file from Vantiv.As of 7.6.1, this batch process uploads and processes response files received from Vantiv when organizations are using Vantiv's authorization/sales recycling feature.
FAR680
creates the EXPORT file and FAR681 IMPORTS the response file from Vantiv.
When an organization is using Vantiv’s authorization/sales recycling feature, credit card transactions are transmitted to Vantiv in a file so that the transactions can be processed in bulk, rather than credit card transactions being transmitted one-by-one. If any credit card transactions fail authorization, Vantiv will continue to try over a pre-defined number of days to obtain authorization. Vantiv returns a response file that contains authorizations and declines, and it is the transaction results in the response file that need to be uploaded into Personify360 and processed.
The
AUTH_RECYCLING_MERCHANT merchant
parameter is used to identify how authorization recycling is managed.
For more information, please see Vantiv
Merchant Parameters.
When a credit card transaction is approved, FAR681 does the following:
Updates Far_Receipt to set AUTHORIZATION_RECYCLING_END_DATE = NULL for the receipt.
Updates the PAYMENT_STATUS_CODE on scheduled payment records from COLLECTION_PENDING to PAID.
Updates appropriate fields in CCP_Req_Ans record with the authorization approved information (i.e., CC_AUTHORIZATION, AUTH_REFERENCE, etc.).
If the response file has a token, the system updates the Cus_Credit_Card_Profile record.
When a credit card transaction is declined in final, FAR681 does the following:
Reverses the payment.
Updates the PAYMENT_STATUS_CODE on scheduled payment records from COLLECTION_PENDING to PENDING.
Updates the CCP_Req_Ans record with the decline information.
Sets the Far_Receipt.RECYCLING_END_DATE to null.
After the FAR680 output file has been submitted to Vantiv’s SFTP server, a response file will be posted within a few minutes that has authorizations and initial decline information. This file will be processed by the FAR681 batch process and will update receipts with credit card authorization numbers; however, credit card transactions that have initially been declined will not be reversed because Vantiv will try to get authorizations over a pre-defined period of time.
The response file provided by Vantiv contains the following data elements:
· <litleResponse> - The root node for the entire response file. Only one is allowed per response file. It contains the following attributes:
o version - Defines the LitleXML schema version against which the XML is validated.
o xmlns - Defines the URI of the schema definition. This is a fixed location and must be specified as: http://www.litle.com/schema.
o response - Indicates whether your XML syntax passed validation. If this value is nonzero, then FAR681 will fail and the XML validation error message will be logged. Expected values are as follows:
§ 0 - XML validation succeeded.
§ 1 - XML validation failed. See the message attribute for more details.
§ 2 - Indicates that the submitted content was either improperly formatted XML or non-XML content.
§ 3 - Indicates that the submission contains empty or invalid credentials (user and password).
§ 4 - Indicates that the merchant has reached the maximum number of concurrent connections.
§ 5 - Indicates that Litle systems may have detected message content that violates certain restrictions.
o message - XML validation error message. Expected values are as follows:
§ If the response attribute returns 0, the message attribute returns the text “Valid Format.”
§ If the response attribute returns 1, the message attribute returns an error message that helps you to identify and troubleshoot the syntax problem.
§ If the response attribute returns 2, the message attribute is "System Error - Call Litle & Co."
§ If the response attribute returns a value of 3, 4, or 5, the message attribute is "There is a problem with the Litle System. Contact support@litle.com."
o litleSessionId - A unique value assigned by Litle to identify the session.
· <batchResponse> - Groups together all transactions that were processed as part of the same batch. Child of the <litleResponse> node. It contains the following attributes:
o id - Returns the same value submitted in the <batchRequest>. Currently not being used.
o litleBatchId - A unique value assigned by Litle to identify the batch.
o merchantId - Returns the same value submitted in the <batchRequest>.
· <authorizationResponse> - Each of these elements corresponds to an authorization request that was submitted as part of the initial batch file. Child of the <batchResponse> element. Each <authorizationResponse> has the following attributes:
o id – A unique identifier equal to the CCP_REQ_ANS_ID field in the CCP_REQ_ANS table. It is equal to the value submitted in the <authorization> transaction.
o reportGroup - Required attribute that defines the merchant sub-group in the user interface where this transaction will be displayed. It is equal to the value submitted in the <authorization> transaction.
In addition, <authorizationResponse> contains the following child elements:
o <litleTxnId> - A unique value assigned by Litle to identify the transaction.
o <orderId> - The receipt number of the transaction.
o <response> - A three digit numeric code which specifies either that the transaction is approved (000 code) or declined.
o <responseTime> - A date/time stamp of the response. The format of the element is YYYY-MM-DDTHH:MM:SS.
o <message> - A brief definition of the response code returned for the transaction.
o <authCode> - (Optional) Specifies the authorization code from the associated Authorization transaction.
o <fraudResult> - (Optional) Contains elements defining any fraud checking results.
o <tokenResponse> - The parent element for several children defining the registered token, as well as the card type and BIN.
o <enhancedAuthResponse> - (Optional) Can provide information concerning whether the card used for the transaction is Prepaid and if so, the available balance. Depending upon the card used, other elements can indicate affluence, card product type, prepaid card type, reloadability and whether or not it is a virtual account number.
o <recycling> -(Optional) Contains a child element that specifies either the recommended date and time for the next recycling attempt for the declined Authorization/Sale transaction or a statement that no further advice is available for merchants using the Recycling Advice feature. For merchants using the Recycling Engine feature, there is a child element that specifies whether or not the engine is recycling the declined transaction.
If
the import fails, please see Troubleshooting
Vantiv Import Failures.
Parameter |
Description |
Required? |
|---|---|---|
Organization |
The Organization ID for which the report will be run. The system sets this to the organization ID of the logged in user running the batch process. |
Read-only |
Organization Unit |
The Organization Unit ID for which you want to run the report. The system sets this to the organization unit of the logged in user running the batch process. |
Read-only |
Run Mode |
Mode in which the report runs: · EDIT – prints the reports. · PROD – prints the reports and updates the database tables. |
Yes |
How should the receipt reversal date be calculated? |
Identifies whether the transaction date used on receipt-reversal transactions should be the same date as the receipt date, or the adjustment batch date (an adjustment batch needs to be open), the current date or a different date specified by the user. |
Yes |
Receipt Reversal Date |
If the How should the receipt reversal date be calculated? parameter is set to "Other Date", enter the date that should be used for all transactions that reverse the receipt created by FAR680. |
No |
Adjustment Batch |
If the How should the receipt reversal date be calculated? parameter is set to "Adjustment Batch Date", enter the name of an adjustment batch; its date will be used for all transactions that reverse the receipt created by FAR680. |
|
Truncate Report Tables? |
If this parameter is set to "Y", if the process is being run in PROD mode, the tables that hold data for reporting will be truncated at the beginning of the process.
The tables that will be truncated if this parameter is set to "Y" are: · FAR681_AUTHORIZED · FAR681_DECLINED · FAR681_EXCEPTIONS. |
Yes |
Input File |
Full path of the input file from which data is to be loaded. Before running this process, you MUST upload the input file. For more information on how to do so, please see Uploading Input Files.
|
Yes |
Vantiv Merchant Id |
As of 7.6.2, this parameter is required when the Input File parameter is blank. FAR681 will download the file processed by Vantiv payment handler if available for this merchant from VANTIV SFTP server (as defined by the SFTP parameters on the Interface Parameter Maintenance (APP018B) screen). The merchant IDs available for selection are defined on the Interface Parameter Maintenance (APP018C) screen. |
No |
Process Type |
As of 7.6.2, select a process type to indicate what type of file to auto process from VANTIV SFTP server. If the process type is set to RESPONSE, the system will auto process Response file(s). If set to RECYCLE, the system will process only recycled files.
|
No |
When processing authorized transactions:
Populate the appropriate fields in the CCP_Req_Ans table
Update payment status of scheduled payments to PAID from COLLECTION_PENDING.
Update Far_Receipt to set AUTHORIZATION_RECYCLING_END_DATE to null
For transactions declined in final by Vantiv:
Reverse payment
The Far_Txn.TXN_DATE should be set based on the parameter values defined for the current run of FAR681 for the RECEIPT REVERSAL DATE METHOD parameter and the RECEIPT_ REVERSAL_ DATE parameter
Update scheduled payment status to PENDING
Set AUTHORIZATION_RECYCLING_END_DATE to null
Update the count and amount values in the Far_Batch_Detail record for the batch that was used for the reversed receipt when it was first created
For transactions with an initial decline but going through authorization recycling, the system writes the LITLE_TXN_ID to Ccp_Req_Ans.AUTH_REFERENCE field.
Records that cannot be processed appear on the FAR681_Exceptions report with the appropriate text that identifies the reason for the error. Examples include (1) cc payments transferred before the Vantiv response file has been processed. Error text for this example would be: (1) Payment has been transferred.
Failure
of one credit card transaction to be able to be processed will not prevent
the rest of the transactions in the file from being processed.
