Reporting APIs
Version
Current Specification Version: V8.2.2
Database Export
Supported Reports
General Information
The purpose of this document is to provide documentation for 3rd parties to integrate with the gateway reporting module.
Financial reporting data is accessible through the gateway in two ways:
1. The most common and recommended method is the reporting API (TidyPay reporting module) allowing to generate and export reports in CSV/PDF/data formats depending on the report type.
2. For the cases when a single front-end system is interacting with the gateway, there is an additional mechanism of Data Export. It enables the front-end system to obtain financial data from the gateway database tables and use it to generate the necessary reports on the integrator’s side.
Financial reporting data is accessible through the gateway in two ways:
1. The most common and recommended method is the reporting API (TidyPay reporting module) allowing to generate and export reports in CSV/PDF/data formats depending on the report type.
2. For the cases when a single front-end system is interacting with the gateway, there is an additional mechanism of Data Export. It enables the front-end system to obtain financial data from the gateway database tables and use it to generate the necessary reports on the integrator’s side.
The connection URL for the sandbox server is: https://[server-name]/reports/[report-name].[report-format]?[parameters], where
https://[server-name]/reports/merchant-statement-list.csv?userName=myUsername&password=myP%40ssword&fromDate=10180101&toDate=20180131&accountId=2001
Authorization is done via service users. To access the API, a service user is required to be granted with a corresponding privilege. A user can submit API requests using either associated credentials or temporary password generated via authentication operation.
When submitting an API request, you can use either TidyPay server URL or the Sanitizing Data Filter (Unibroker) server URL as an endpoint.
Requests that contain tokenized card numbers/bank account numbers can be submitted directly to {Unipay} server.
To reduce PCI exposure, requests with non-tokenized (raw) account data should be passed through the sanitizing data filter server. Otherwise, L04 error will be returned (Processing of raw account data is not allowed through the specified API end-point for the current user).
If you don’t have a specific reason, we recommend sending all the requests to the same endpoint (data filter).
To learn more about service users and end-points used for API submission, review Security Management guide.
See Security Management guide for more information.
Request method is GET. The content-type must be set to application/x-www-form-urlencoded.
Request fields are passed within HTTPS request body (including cases with callbacks) and are required to be URL-encoded.
Response fields are passed within HTTPS response body.
Both request and response field values are passed using name1=key1&name2=key2 format.
- [report-name] is a name of a report;
- [report-format] - format in which the report is generated, see integration notes for more information;
- [parameters] - fields in the report request, indicating what data is going to be included in the report.
https://[server-name]/reports/merchant-statement-list.csv?userName=myUsername&password=myP%40ssword&fromDate=10180101&toDate=20180131&accountId=2001
Authorization is done via service users. To access the API, a service user is required to be granted with a corresponding privilege. A user can submit API requests using either associated credentials or temporary password generated via authentication operation.
When submitting an API request, you can use either TidyPay server URL or the Sanitizing Data Filter (Unibroker) server URL as an endpoint.
Requests that contain tokenized card numbers/bank account numbers can be submitted directly to {Unipay} server.
To reduce PCI exposure, requests with non-tokenized (raw) account data should be passed through the sanitizing data filter server. Otherwise, L04 error will be returned (Processing of raw account data is not allowed through the specified API end-point for the current user).
If you don’t have a specific reason, we recommend sending all the requests to the same endpoint (data filter).
To learn more about service users and end-points used for API submission, review Security Management guide.
See Security Management guide for more information.
Request method is GET. The content-type must be set to application/x-www-form-urlencoded.
Request fields are passed within HTTPS request body (including cases with callbacks) and are required to be URL-encoded.
Response fields are passed within HTTPS response body.
Both request and response field values are passed using name1=key1&name2=key2 format.
Supported Reports
Database Export
Corresponds to StatementListExport database table. The table contains general information about merchant statements including total and net amounts of submissions, merchant fees, reserves, splits, etc.
Corresponds to StatementDetailListExport database table. The table contains information about statement details grouped by submission ID and stereotype.
Corresponds to StatementFeeDetailListExport database table.
The table contains information about all fee amounts and rates related to merchant statements, including per item, flat, intercharge, assessment, and service fees.
The table contains information about all fee amounts and rates related to merchant statements, including per item, flat, intercharge, assessment, and service fees.
Corresponds to TransactionListExport database table. The table contains the list of transactions contained in merchant statements and details of the transactions including the identifiers of associated entities (merchant account, reseller), payment account and billing information, and related fees amounts.
Provides all merchant statements associated with the specified account. The report is uzed to analyze all fees and deposits processed by the account within a specified date range. Generated in CSV and data formats.
Provides a deposit or reconciliation statement associated with the specified statement identifier. Generated in PDF format.
Provides all reseller statements associated with the specified reseller. The report is used to analyze all fees and deposits processed by the merchants/accounts under the reseller within a specified date range. Generated in CSV and data formats.
Provides a reseller statement with aggregated information across all merchants associated with a particular reseller. Generated in PDF format.
Provides a reseller statement with information for one merchant associated with the specified reseller. Generated in PDF format.
Provides a list of deposits received by the account within a specified date range. Generated in CSV and data formats.
Provides a list of transactions associated with the specified account. Generated in CSV and data formats.
Provides a list of the related transactions associated with the specified one. Generated in CSV and data formats.
Note: This report is available for Vantiv Tandem and TrustCommerce processors only.
The report is available only for transactions processed in realtime. If the requested transaction has been processed in a batch file, S29 (No data is available for the specified criteria) error is returned.
The report is available only for transactions processed in realtime. If the requested transaction has been processed in a batch file, S29 (No data is available for the specified criteria) error is returned.
Provides a gateway-generated receipt associated with the specified transaction identifier. Generated in PDF format.
Provides a list of split transactions associated with the specified account. The report is available for the transactions that are not older than 92 days. Generated in CSV and data formats.
Provides a monthly statement and reconсiliation statement associated with the specified account. Generated in PDF format.
Message Formats
Usage:
| R | - | required in request/always present in response for direct debit transactions and credit card transactions of all levels (I, II, III). |
| O | - | optional in request/not always present in response. |
| C | - | conditional; conditions of the usage are defined below the corresponding section. |
| E | - | echo back from request; if present in request, it is present in response, if it is not present in request, it is not present in response. |
| R2 | - | required in request/always present in response for credit card transactions of level II and III only; optional for direct debit and level I credit card transactions. |
| R3 | - | required in request/always present in response for credit card transactions of III only; optional for direct debit and level I, II credit card transactions. |
| SR | - | required in request/always present in response for split transactions only. |
| I | - | for internal use only. |
| N | - | not used. |
| * | - | required fields in these specific sections are only required if this specific feature is used. |
Copyright ©
TidyPay. All Rights Reserved.
All Logos and Trademarks used or mentioned on this page are copyrighted property of their respective owners and are used for display purposes only.