Best Practices

The Transaction Reporting API offers several reporting methods that can be used to retrieve data, including transaction statuses, settlement statuses, and transaction events. The method calls that will be used is dependent on what information is needed to update your front-end system. This guide provides the best practices set of methods that is used most often.

Reporting Guidelines and Restrictions

On all reporting requests there are some guidelines and restrictions that must be adhered to for quality purposes. Each of the following items will be validated during your web service certification to ensure that EPS standards are met before production use.

• No more than 5 threads at a time should be used by the sending application.
• Failed credential scenarios should not continuously retry in a loop.
• Health check monitors hitting the system will not be permitted.
• Reports should not exceed retrieving data for the previous 3 business days.
• Reports should only repeat calls on batches or items in cases of no response or timeout of the original request.
• Systems should be designed to wait 10 minutes to receive a report response before timing out.
• Reports should be limited by employing logic to only retrieve data on batches or items you do not already have.

Best Practices API Methods

API Methods	Notes/Comments
CreditandDebitReports	This call can be used to report the movement of funds in/out of the merchant settlement account. The response data will include both credits (for originations) and debits (for chargebacks or refunds). No transaction details are provided in the response (only batch summary info). If transaction details of a batch are desired see CreditandDebitsTransactionDetailReport .
CreditsandDebitsTransactionDetailReport	This call can be used to report on the transaction details that make up a settlement item (batch) to the merchant settlement account. BatchID should be pulled from the CreditandDebitReports call and passed into the detail report call.
GetHistoricalEvents	This call will provide back information on Transaction Events and Statuses that have taken place on transactions. Transaction_Number or Reference_Number should be used to match back transactions in the integrator’s front-end system. As a best practice, it should be called at a minimum of twice per day (after Midnight CT and after Noon CT) beginTransDate and endTransDate represent the event date/time, not the transaction date/time. Using these fields allows integrators to provide the window of time to pull back events (i.e. only “new” events since the last call) Using wsdisplayFields, the integrator can limit the data that is included in the response Using the wstransEvents, a request can be built to only report events that match certain criteria. Example, the following wstransEvents will only report back “returns” Disputed Returned_NSF Returned_Bad_Account Unauthorized Other_Check21_Returns The ReturnCode field will provide the return reason (R-Code) for why the transaction was returned. A list of R-Codes and their corresponding descriptions can be found further down in this Transaction Reporting section. Notification of Change (NOC) processing- an event type of Notice_Of_Change (wstransEvents) will report back all received NOC’s for the period specified by beginTransDate and endTransDate. The NoticeOfChange value in the response data will include the change code and description. The EventDatastring will include the details. Ex: NoticeOfChange: C01 Description EventDatastring: Account Number: old = 12345 / new = 987654 NoticeOfChange: C02 Description EventDatastring: Routing Number: old = 123456789 / new = 987654321 NoticeOfChange: C03 Description EventDatastring: Routing Number: old = 123456789 / new = 987654321 Account Number: old = 12345 / new = 987654 NoticeOfChange: C05 Description EventDatastring: Account Type: old = Savings_Debit / new = DDA_Debit NoticeOfChange: C06 Description EventDatastring: Account Number: old = 12345 / new = 987654 Account Type: old = DDA_Credit / new = Savings_Credit NoticeOfChange: C07 Description EventDatastring: Routing Number: old = 123456789 / new = 987654321 Account Number: old = 12345 / new = 987654 Account Type: old = Savings_Debit / new = DDA_Debit EPS will auto-correct future transactions that have incorrect RT/Account Type/Account Number information, for a period of two years. However, this does not preclude the integrator from their obligations per the NACHA rules to notify their originators of the change information, so it can be corrected at the source.