Vantiv Authorization Recycling

Vantiv offers a service called "Authorization Recycling", which is a process by which Vantiv attempts to secure authorizations for declined credit card transactions over a period of 15-28 days. "Authorization Recycling" requires that credit-card transactions be submitted to Vantiv for bulk credit-card transaction processing.

As of 7.6.1, FAR680 has been modified and FAR681 and FND681 has been implemented to support "Authorization Recycling". FAR680 and FND681 create the EXPORT file(s) and FAR681 and FND681 IMPORTS the response file(s) from Vantiv. As of 7.6.2, the process of sending the SFTP export file created by FAR680 and FND681 to the Vantiv site is automatic.

Vantiv refers to bulk transaction processing as "batch processing". However, we are referring to it as "bulk transaction processing" to avoid confusing with Personify360 batch processing.

Bulk Transaction Processing Format

Each batch transmission you send to Vantiv is considered to be a single request. You can think of the entire batch request as a session composed of one or more individual batches, each containing one or more transactions. You can also use a batch as a request for retrieval of the response for a previously processed session. Each request results in a response transmission sent from Vantiv to you. Batch submissions supports all transaction types except those marked as online only, most notably void, eCheckVoid, and several Gift Card transactions.

Several Value Added Services provide daily (or as needed) Batch files with information about transactions processed the previous day. For example, if you use the Litle Recurring Engine, the system creates a Batch file containing the responses for the recurring transactions processed the prior day.

The Batch processing request is made up of the following elements:

Encrypted FTP (PGP or GPG key encryption)
sFTP
TCP/IP Socket (using SSL)
Header information - one <litleRequest> element
Merchant authentication information - one <authentication> element
Batch information - one or more <batchRequest> elements
Payment transactions (for example, an Authorization, Capture, Credit, etc.) - at least one per <batchRequest> element

The Batch processing response is composed of the following elements:

At least one payment transaction response (for example, an Authorization response, Capture response, Credit response, etc.).
Header information - one <litleResponse> element
One or more <batchResponse> elements - contains payment transactions response.

Credit Card Type Recycling

When a payment is created for a credit card that is being submitted to authorization recycling, the activities that can be done on that payment are restricted until the final authorization is received. As of 7.6.1, a new field was added to the Far_Receipt record called AUTHORIZATION_RECYCLING_END_DATE.

When a credit card receipt is created that is being submitted for authorization recycling, the AUTHORIZATION_RECYCLING_END_DATE will be set to the receipt date plus the maximum number of days it might take to get an authorization or final decline. If that field is not null and if the date in that field is greater than the current date, users will not be able to refund or transfer that receipt.

At the credit card type level (i.e., CCP "CREDIT_CARD_TYPE" system type), use the Vantiv Auth. Recycling Days (App_Code.OPTION_6) field to record the number of days that Vantiv will continue to try to obtain an authorization for a declined transaction. The value in this field will be used to populate Far_Receipt.AUTHORIZATION_RECYCLE_END_DATE.

FAR680

At a high-level, the steps in the process are:

· FAR680

§ FAR680 run in bulk transaction processing mode (i.e., "Use Vantiv Batch Processing" = Y):

o A receipt record will be created for order lines with current scheduled credit-card payments that are due

o The scheduled payment will be updated with a payment status of "PAID"

o A pre-sale record will be created in Ccp_Req_Ans without a value in the cc authorization or authorization reference fields

§ An export file will be created that will be transmitted to Vantiv for processing

As of 7.6.2, you can automate the process of sending the SFTP file to Vantiv.

§ A hold period will be implemented to restrict refunds and payment transfers for credit card payments going through authorization recycling.

§ If the payment is reversed before the final authorization status is received from Vantiv (i.e., while the credit card transaction is undergoing authorization recycling), an "Authorization Reversal" transaction will be generated.

When FAR680 is run with the Use Vantiv Batch Processing? parameter set to "Y", for each scheduled payment selected for processing, FAR680 will:

· Create a Type 1 receipt record in Far_Txn

· Create a record in Far_Receipt with AUTHORIZATION_RECYCLING_END_DATE field populated:

§ Create a new field in Far_Receipt called AUTHORIZATION_RECYCLING_END_DATE (datatype: datetime; nullable)

§ Set Far_Receipt. AUTHORIZATION_RECYCLING_END_DATE = Far_Txn.TXN_DATE + days defined in App_Code.OPTION_6 for the credit card type of the credit card payment where Far_Txn.TXN_TYPE_CODE = 1 and Far_Txn.RECEIPT_NO = Far_Receipt.RECEIPT_NO and App_Code.SUBSYSTEM = ‘CCP’ and App_Code.TYPE = ‘CREDIT_CARD_TYPE’ and App_Code.CODE = Far_Receipt.RECEIPT_TYPE_CODE

· Create AR and CASH records in Far_Txn_Detail.

· Update selected scheduled payment records with a payment status of PAID

· Create a pre-sale record in Ccp_Req_Ans where CC_AUTHORIZATION and AUTH_REFERENCE are NULL

When FAR680 is run in PROD mode with the Use Vantiv Batch Processing? parameter set to "Y", the system will generate an output file with the following data elements:

· <litleRequest> - The root node for the entire batch file. Only one is allowed per batch file. It contains the following attributes:

§ version - Defines the LitleXML schema version against which the XML is validated.

§ xmlns - Defines the URI of the schema definition. This is a fixed location and must be specified as: http://www.litle.com/schema.

§ numBatchRequests - Defines the total number of <batchRequest> children included in the <litleRequest>.

· <authentication> - Contains information about the authentication of the merchant. Child of the <litleRequest> node. Only one is allowed per batch file. It has two child nodes:

§ <user> - A unique identifier of the user/merchant used to authenticate that the message is from a valid source.

§ <password> - Used in combination with the <user> element to authenticate that the message is from a valid source.

· <batchRequest> - Groups together all transactions that are to be processed as part of the same batch. Child of the <litleRequest> node. Each file must contain one or more <batchRequest> elements. It contains the following attributes:

§ id - A unique string to identify this <batchRequest> within the Litle system. Currently not being used.

§ numAuths - Defines the total count of Authorization transactions in the <batchRequest>.

§ authAmount - Defines the total dollar amount of Authorization transactions in the batchRequest. The decimal point is implied. For example, you enter $25.00 as 2500.

§ merchantSdk – This attribute is undocumented in the Litle Reference Guide

§ merchantId - A unique string to identify the merchant within the Litle system.

· <authorization> - Each of these elements corresponds to a different receipt for which the merchant is requesting authorization. Child of the <batchRequest> element. Each <batchRequest> must contain one or more <authorization> elements. Each <authorization> has the following attributes:

§ id – A unique identifier equal to “FAR680_” + the CCP_REQ_ANS_ID field in the CCP_REQ_ANS table. It will be mirrored back in the response file.

§ reportGroup - Required attribute that defines the merchant sub-group in the user interface where this transaction will be displayed. Set in Merchant Setup in APP014.

In addition, <authorization> contains the following child elements:

§ <orderId> - The receipt number of the transaction.

§ <amount> - Defines the amount of the transaction. The decimal point is implied. For example, you enter $25.00 as 2500.

§ <orderSource> - Defines the order entry source for the type of transaction.

§ <token> - Contains either a Litle generated token or a Paypal generated token.

§ <recyclingRequest> - (Optional) If present, this indicates that the merchant would like Vantiv to reattempt authorizations for failed transactions. This is done automatically by the Litle Recycling Engine if it has been set up for the merchant. The maximum number of retries is 4 attempts in 16 days for VISA, and 8 attempts in 28 days for MasterCard and Discover. It has an optional <recycleBy> child element that indicates whether the merchant or the Litle Recycling Engine will control the recycling of the transaction.

The output file will be saved to the location defined by the REQUEST DIRECTORY interface parameter.

FAR681

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.

FND681

Personify360 supports recurring gifts. Currently, recurring gifts must be paid by credit card. The FND680 batch process creates order lines and receipt records for recurring gift payments once credit card authorization is received. Organizations using Vantiv's authorization recycling for recurring donations need to run FND681 instead of FND680.

Note that FAR680 uses a parameter called "Use Vantiv Batch Processing?". This parameter is not necessary for FND681, because the only reason to use FND681 is if the organization is using Vantiv as their payment handler and if they want to use Vantiv’s authorization recycling feature.

At a high-level, the FND681 EXPORT process:

· FND681 is run with PROCESSING_MODE set to EXPORT and RUN_MODE is set to PROD:

o A record is created for transmission to Vantiv for each recurring gift payment that is due.

o The RECURRING_GIFT_STATUS_CODE of the "renewed from" order line will be updated from "ACTIVE" to "IN_PROCESS". This will later be updated based on whether collection is successful or not.

o An export file will be created that will be transmitted to Vantiv for processing.

The XML-formatted output file will be saved to the location defined by the REQUESTDIRECTORY interface parameter.

If the fundraising recurring gift product has been defined with a custom billing description, it will be passed to Vantiv in the export file, rather than the order line description.

At a high-level, FND681 IMPORT process identifies whether the credit card transaction is (1) successfully authorized, (2) initially declined but is going through sales recycling, or (3) declined and will not go through additional authorization recycling. This is done whether FND681 is being run in PROD or EDIT mode.

· If a credit card transaction for a recurring gift is successful authorized, if the RUN_MODE = "PROD", FND681 will:

o Either create a new receipt batch or open the receipt batch specified by the user in the FND681 Batch parameter.

o Create Order_Detail and Order_Fnd_Detail record for each paid recurring gift with Order_Fnd_Detail.RECURRING_GIFT_STATUS_CODE set to "ACTIVE".

o Update Order_Fnd_Detail.RECURRING_GIFT_STATUS_CODE on the “renewed from” (previous successfully collected recurring gift order line) from "IN_PROCESS" to "RENEWED".

o For each recurring gift order or order line, create receipt records in:

§ Order_Detail_CC_Info

§ Far_Receipt

§ Far_Txn (TXN_TYPE_CODE = 1)

§ Appropriate records in Far_Txn_Detail based on GL account setup (will include TXN_FUNCTION_CODE values of REVENUE and CASH; there may be DUETO and DUEFROM transactions)

o Create appropriate hard and soft credit records in Fnd_Credit.

o Create record in CCP_Req_Ans with REQ_TYPE_CODE = ‘PRE-SALE’, APPROVED_FLAG = ‘Y’ and CC_AUTHORIZATION, CC_REFERENCE, SETTLEMENT_NO and other field values populated (unlike most records in CCP_Req_Ans that involve two steps, this will be a single record for the credit card transaction).

§ If response is a Hard or Soft decline, then APPROVED_FLAG is set to 'N' and SETTLEMENT_NO gets updated by the CCP610 process.

o If the record has a token, update Cus_Credit_Card_Profile with the token and update the PROFILE_DATE.

· If credit card transactions are declined and the recycling element is true, it means that the credit card transaction has been declined but the transaction will go through authorization recycling, and FND681 does not need to do any data updates for that transaction, but it should appear on the decline report, with the phrase “; pending authorization recycling” after the decline reason.

· If credit card transactions are declined and the recycling element is false, it either means that the initial credit card decline was a hard decline or the credit card transaction has gone through the authorization recycling process and could not be successfully authorized, so the decline is a final decline. In that scenario, FND681 will:

o Update RECURRING_GIFT_STATUS_CODE on the "renewed from" (previous recurring gift order line) from "IN_PROCESS" to "REJECTED".

o Create record in Ccp_Req_Ans to record the credit card decline (Note that the Ccp_Req_Ans.RECEIPT_NO value should be generated from App_Next_Number_Far_Receipt.NEXT_ID, but no Far_Receipt record will be created).