All Categories ​ > ​ ​LMS API ​ > ​     API – Payment Report

API – Payment Report

Updated 1 month ago by Sloan

General

LoanPro’s payment report offers detailed information about payments made and which loans the payments were applied towards. Each time a payment report is pulled a query is used to specify what gets pulled based off of either the payment information and/or the loan information. This gives great power and flexibility to pull detailed reports about specific or generalized payment histories.

There are many aspects to a payload, and this article will cover the basics and provide links to resources to learn more about how each element works.

Request URL

You'll send the request to this endpoint:

POST https://loanpro.simnang.com/api/public/api/1/Autopal.PaymentReport

All requests sent to this endpoint will be a POST request. Please note that this is different than many other requests to get data where GET requests are used. This is due to the payload sizes becoming potentially large and to keep the URLs readable.

Payload Sections

There are two main sections to the payload:

  • query
  • reportOptions

Each section contains an integral part to the query of the data, and each has its own parameters and format.

Query

The query section is formatted as follows:

"query": {
        "query": {
            <query data>
        }
    }

These queries are modeled after the queries used by Elastic search and are discussed more in depth in the article API Query Objects.

Report Options

The report options section is where field specific to the Payments Report are placed. These fields are outlined below:

  • method – Restrict by payment method. Values can be found in Settings > Loan > Payments > Methods. Values are the titles of payment methods, not the IDs. Use “all” to search for payments using any payment method.
  • type – Restrict by payment type. Values can be found in Settings > Loan > Payments > types. Values are the titles of payment types, not the IDs. Use “all” to search for payments of any type.
  • status – Restrict by payment status. Values are “all” for any status, “new” for newly created payments, and “edited” for edited payments
  • reversereason – deprecated. Defaults to “all”
  • period – The application date period. Defaults to “today”. Values are:
    • today – for payments applying today
    • tw – for payments applying this week
    • td – for the past 30 days
    • mtd – for Month to Date
    • ytd – for Year to Date
    • yesterday – For payments applied Yesterday
    • lw – for last week
    • lm – for last month
    • custom – for a custom date range (specified by dateFrom and dateTo)
    • other – for a different date range (specified by dateFrom and dateTo)
  • dateFrom  – The starting date for the application date range. Formatted with the ISO 8601 Format
  • dateTo  – The ending date for the application date range. Formatted with the ISO 8601 Format
  • changedPeriod – the date period for when the payment was last changed. Same values as the period field.
  • changedDateFrom – The starting date for the payment changed date range. Defaults to “today”. Formatted with the ISO 8601 Format
  • changedDateTo – The starting date for the payment changed date range. Formatted with the ISO 8601 Format
  • sourceCompanies – an array of JSON objects, each containing an integer “id” of a source company id to match against. It matches against source companies with an or operation (Ex. “Do loans have source company 1 or source company 2?”)
  • portfoliosCriteria – deprecated. Use the query object instead (“portfolios” is the field for portfolios, subPortfolios.portfolio__N is the field for the subportfolios where “N” is the ID of the portfolio).
  • splitPayments – Whether or not to restrict to only split payments. Values: “all” – don’t restrict to split payments; “yes” – restrict to only split payments; “no” – exclude all split payments
  • processorStatus – This will be aligned with the Secure Payments status of the payment. The available options are "PENDING", "PROCESSING", "VOIDED", "FAILED", "SETTLED SUCCESSFULLY"
  • dateEnteredPeriod – The period for when the payment was entered into the system. Same values as the period field.
  • dateEnteredTo – The starting date for the payment entered date range. Defaults to “today”. Formatted with the ISO 8601 Format
  • dateEnteredFrom – The ending date for the payment entered date range. Defaults to “today”. Formatted with the ISO 8601 Format
  • chargeOff – Whether or not to restrict by charge off. Values: “all” – don’t restrict to charge offs; “yes” – restrict to only charge offs; “no” – exclude all charge offs
  • postedBy – Text to match in the description of who posted the payment
  • customFields – This only supports payment custom fields of “select” type.

 Below is an example of the reportOptions object, which makes up the second half of the payload:

"reportOptions": {
    "method": "all",
    "type": "all",
    "status": "all",
    "reversereason": "all",
    "chargeOff": "all",
    "period": "other",
    "dateFrom": "2000-01-01T00:00:01",
    "dateTo": "2030-01-01T23:59:59",
    "changedPeriod": "other",
    "changedDateFrom": "2000-01-01T00:00:01",
    "changedDateTo": "2030-01-01T23:59:59",
    "portfoliosCriteria": "all",
    "splitPayments": "all",
    "batchId": "",
    "processorStatus": "",
    "dateEnteredPeriod": "other",
    "dateEnteredTo": "",
    "dateEnteredFrom": "",
    "chargeOffRecovery": "all"
  }

Putting it all Together

Below is a sample request that pulls all active loans with a loan status id of 7431. The payments were applied between 2000 and 2030 and last edited in the same time frame. There are no other restrictions.

{
  "query": {
    "bool": {
      "must": [
        {
          "bool": {
            "should": [
              {
                "match": {
                  "id": 7431
                }
              },
              {
                "query_string": {
                  "query": "*id=7431*",
                  "analyzer": "standard",
                  "fields": [
                    "title",
                    "displayId",
                    "collateral.vin",
                    "collateral.color",
                    "collateral.gpsCode",
                    "collateral.licensePlate",
                    "collateralInfo",
                    "primaryCustomerName",
                    "secondaryCustomerName",
                    "primaryCustomerAddress.city",
                    "primaryCustomerAddress.zipcode",
                    "primaryCustomerAddress.state",
                    "secondaryCustomerAddress.city",
                    "secondaryCustomerAddress.zipcode",
                    "secondaryCustomerAddress.state",
                    "primaryPhone",
                    "secondaryPhone",
                    "insurance.companyName",
                    "insurance.insured",
                    "insurance.policyNumber",
                    "insurance.agentName",
                    "customFields",
                    "bankruptcyCaseNumber"
                  ],
                  "default_operator": "and"
                }
              }
            ]
          }
        }
      ]
    }
  },
  "reportOptions": {
    "method": "all",
    "type": "all",
    "status": "all",
    "reversereason": "all",
    "chargeOff": "all",
    "period": "other",
    "dateFrom": "2000-01-01T00:00:01",
    "dateTo": "2030-01-01T23:59:59",
    "changedPeriod": "other",
    "changedDateFrom": "2000-01-01T00:00:01",
    "changedDateTo": "2030-01-01T23:59:59",
    "portfoliosCriteria": "all",
    "splitPayments": "all",
    "batchId": "",
    "processorStatus": "",
    "dateEnteredPeriod": "other",
    "dateEnteredTo": "",
    "dateEnteredFrom": "",
    "chargeOffRecovery": "all"
  }
}

Results and Pagination

Because there is such a large number of payment records that is usually available in the payments report, pagination works slightly differently than it does for entities with less records. When specifying the number of records the report should return, things work normally. For example, if you want 10 records from the payments report, you can use the endpoint:

POST https://loanpro.simnang.com/api/public/api/1/Autopal.PaymentReport?$top=10

The $top token specifies how many records should be returned.

The difference comes when you want to specify the second page of results, or you want results to start in a specific place. In this case you can use the endpoint:

POST https://loanpro.simnang.com/api/public/api/1/Autopal.PaymentReport?$top=10&$start=10564

The $top token is present, specifying 10 results will be returned, but the $start token is also used. The $start token is being set to the ID of a specific record. In this case, the transaction ID. So, when the results are returned, each record looks something like:

{
  "loanId": 296,
  "tranId": "10564", 
  "tranCreated": "2018-11-13 16:04:37",
  "tranApplyDate": "2018-11-13 00:00:00",
  "tranPaymentDate": "2018-11-13",
  "tranDisplayId": 6232,
   ...

Because the tranId for this record was used as the value of the $start token, this will be the first record that is returned. If you want to show pages of 10 payments, starting with this payment, you will need to use the ID of the last payment returned as the value of the $start token, when returning the values for the next page.

For example, if the results of that last request (starting at 10564) have the following tranIds:

  • tranId: 10565
  • tranId: 10566
  • tranId: 10568
  • tranId: 10571
  • tranId: 10574
  • tranId: 10575
  • tranId: 10578
  • tranId: 10580
  • tranId: 10581
  • tranId: 10583

You would use the tranId 10583 to know where to start the next page. The call would be:

POST https://loanpro.simnang.com/api/public/api/1/Autopal.PaymentReport?$top=10&$start=10583

Note that the ID used as the value of $start is not included in the results.

How did we do?

Powered by HelpDocs (opens in a new tab)