The TWP Integration supports importing of data using CSV files. This document describes the format of the CSV file and the process for importing it.
CSV File Format
- The CSV file must be an ASCII text file. Unicode characters are not supported.
- Each line of the CSV file must end with a carriage return line feed combination (ASCI 13, and 10).
- The first row in the file must be a header row consisting of the fields you are including.
- Carriage returns and line feeds cannot exist in any data fields.
- A carriage return/line feed is not required on the last row of data (but is allowed)
- Any blank line in the file is ignored.
- The following fields are required in every file. Other fields are optional.
- Any field not included is treated as if you set it to its default value.
- boolean: false
- string: blank
- date: blank
- number: zero or blank
- Every file must have a unique name. We recommend using a date or time stamp.
- Dates must be in the format YYYY-MM-DD.
- Boolean fields can be either “true” or “false”. A value of blank (“”) will be treated as “false”.
- Custom fields are treated as text fields so you may use any format you want to indicate dates (i.e. “Monday, May 5th, 2020”).
The header row (the first row in the file) may contain any number of field names from the list of supported fields (see below). There is no specific order required for the fields. The field names are case sensitive. Any field name that is not recognized will cause an error. You may also include any number of custom fields. (See Custom Fields section below.)
In addition to the supported fields, you may have any number of custom fields. All custom fields are treated as text and will show up exactly how you supply them. Custom fields must be prefixed with and asterisk (*). This lets the import know that it is not a standard field. Custom fields should not reuse any existing field names. They should contain only letters and numbers. Examples are show below:
Each payment consists of 3 fields which are all combined to make up a payment record. The 3 fields are:
Each consumer record may have up to 100 payments. When specifying payments, start with the suffix of ‘1’ for each field name and increment it for each payment. You do not need to put the payments in any specific order. The system will sort them by date regardless the order in the data file. The Amount and Date fields are required for each payment. The Description field is optional.
Below is an example of the payment fields in a record:
100.00,2020-01-15,150.00,2020-02-15,Check Payment,Online Payment
Post Date Fields
Post Dates use the same logic as Payments except their fieldnames are:
Below are multiple examples of file that contain only one record (for simplicity). Your file can contain any number of fields and records. Because of word wrap, some records appear to extend onto multiple lines. That would not be the case when saving in a CSV file.
Example 2 – Simple File:
Example 2 – More Fields:
12345,John Doe,John,Doe,2000.55,true,true,false,ACME Credit
Example 3 – With Custom Fields:
12345,John Doe,John,Doe,2000.55,true,true,false,ACME Credit,Jane Doe,Loan
A unique identifier for each account. Sometimes called the Reference Number or account number. This should never change.
Allows the consumer to view the account information. If this is set to true a user sees their account information. When set to false, some of their information will show up as “unavailable” and they will not be able to make payment. This can be used to disable access to a single account without removing it.
Complete name of primary account holder
First name of the primary account holder
Last name of the primary account holder
Address of account holder
City of account holder
State of account holder
Zip code of account holder
The email address for the account holder
Social security number (or the last 4 of the SSN)
Date of birth
The beginning balance when the account was assigned
The date the account was assigned
The current balance on the account
Can the user make a payment on this account? By default, they will be prevented from making a payment, if the balance is zero. However, you can prevent payments for other reasons (i.e. Complaint, Settlement, already scheduled payments).
True if single ACH Payments are allowed. False otherwise.
True if credit cards will be accepted for this account, false otherwise.
True if debit cards will be accepted for this account, false otherwise. (bin detection component required)
True if recurring checking account (ACH) payments are allowed
True if recurring credit card payments are allowed (must be supported by your gateway)
True if recurring debit card payments are allowed (must be supported by your gateway)
True if a settlement was offered on this account, false otherwise
The amount of the settlement that was offered on this account.
The maximum number of payments allowed for a settlement on this account.
The last date a payment can be schedule to complete a settlement arrangement.
A unique client ID used to identify the client in the integrated system
The status of the account. This is an internal status and will NOT be shown to the user.
The status of the account that can be displayed to the user. If not specified this will not be shown. This is visible to the user. Do NOT use internal statuses.
The account number that was originally assigned to the account.
The name of the original creditor
The name of the client.
The name of the collector assigned to this account. This is a shorter name used if you want to abbreviate or use a desk.
The name of the collector assigned to this account.
The phone number to reach the collector.
Amount of the payment (see payment fields)
Date of the payment (see payment fields)
Description of the payment (max 50 characters) (see payment fields)
Amount of the postdate (see postdate fields)
Date of the postdate (see postdate fields)
Description of the postdate (max 50 characters) (see postdate fields)
Allow ACH for Settlements. Only applicable when there is a settlement offer. This field may be null. This field is unlike standard boolean fields as it will not default to false if left null. Instead, it will use the system default setting.
Allow Credit Cards for Settlements. Only applicable when there is a settlement offer. This field may be null. This field is unlike standard boolean fields as it will not default to false if left null. Instead, it will use the system default setting.
Allow Debit Cards for Settlements. Only applicable when there is a settlement offer. This field may be null. This field is unlike standard boolean fields as it will not default to false if left null. Instead, it will use the system default setting.
|*CellPhone||This field can be used for texting features.|
NOTE: this field is formatted as a custom field and has the asterisk prefix. It is essentially a "reserved" custom field that is treated as a regular field. There are internal/backwards compatibility reasons why this field is named differently.
Accepted formats are:
The fields below are not data fields for the account. Instead, they are action fields that can be included with an account. They will cause an action to occur after the import of the file.
This field may contain the internal template name of one of your email templates. When this field contains a value, an email batch will be created after the file is imported. This field and any values in it are optional. You can add a value on some records and not on others. Any value that is included must be a valid email template name.
What is the format of the data file?
The format details of the CSV file are listed below this section. The format has standard fields and allows for unlimited custom fields.
How often should I upload the data file?
We recommend uploading a new data file once per day. This ensures that the consumer information is no more than one (1) day old, provided up-to-date information to Consumers.
Do you support real-time/live data access instead of having day old data?
Yes – advanced setups are available that allow your data to be live on the website. These setups require integration software and setup by your Agency. This setup has advantages but requires that you have the IT personnel to install/manage/troubleshoot. There is also an additional fee for this setup.
How do I upload the file?
Your agency will have access to an SFTP site. You may use any tool that supports SFTP to upload your file, or you may automate a process that uploads the file on a regular basis.
How long does it take to import my data?
Our systems run 24/7 and look for any new data files. Most data files are processed within one (1) hour of uploading; larger files may take more time. These processes seamlessly run behind the scenes, making the solution full accessible to all users and Consumers while the data is imported.
Can we import other types of files?
If you are unable to produce the standard data import files, our team can work with you to create a custom import that will read the format you are able to produce and import it. Additional technical programming costs apply.