.csv format and are designed to integrate directly into your existing reconciliation and financial workflows.
Daily Reporting
Reports are generated on a 24-hour cycle and cover the full prior day’s activity. Delivery is via secure SFTP. Ingo can push files directly to your host environment or provide pull-based access — both are supported. Authentication supports either username/password or SSH key configurations. File encryption is available but not required, as reports do not contain PII or PCI-sensitive data.File naming conventions
Each daily report file follows a standard naming pattern that identifies the client, direction (push or pull), and timestamp:Participant-ID value is a 5 Integer value assigned by Ingo at onboarding.
Reconciliation
Running both daily and monthly reconciliation gives you the most complete picture of your disbursement activity. Daily reconciliation catches errors, duplicates, and unauthorized payments in near real-time — before discrepancies compound. Monthly reconciliation validates that all transactions are fully recorded, correctly classified, and aligned with your general ledger. Together, they maintain cash visibility, support financial forecasting, and produce the audit-ready documentation needed for financial close.Transaction Types
Every transaction in the daily report carries a type code that identifies its nature. Seven transaction types may appear across your push and pull activity:| Type Code | Name | Description |
|---|---|---|
1 | Credit Origination | An original push transaction that credits funds to a consumer’s account. |
5 | Debit Origination | An original pull transaction that debits funds from a consumer’s account. |
10 | Return — Push | The original push transaction was not accepted by the issuing bank and has been returned to Ingo. Most common on push-to-credit-card transactions. Also triggered by consumer or issuer-initiated disputes and chargebacks. Returns typically occur days after the original disbursement. |
14 | Refund | The original push or pull transaction was accepted by Ingo but declined by the issuing bank or payment network — typically because the consumer’s account is not in good standing. Refunds are generally created in real time. |
19 | Return — Pull | The original pull transaction was not accepted by the issuing bank and has been returned to Ingo. Most common on pull-from-account transactions. Also triggered by consumer or issuer-initiated disputes and chargebacks. Returns typically occur days after the original request. |
24 | Adjustment Credit | A settlement credit adjustment to an original push or pull transaction that was accepted by both Ingo and the issuer. Issued in response to a transaction-related event after the transaction has settled. |
25 | Adjustment Debit | A settlement debit adjustment to an original push or pull transaction that was accepted by both Ingo and the issuer. Issued in response to a transaction-related event after the transaction has settled. The reason for the adjustment is indicated by the reported reason code. |
Account Types
Theaccount_type field in each report record uses the following codes:
| Code | Payment Type |
|---|---|
AC | Standard ACH |
BP | BillPay |
CA | Card |
CK | Check by Mail |
PD | PayPal (Verified) |
PE | PayPal (Unverified) |
RT | Real-Time Payments (RTP) |
SD | Same-Day ACH |
VE | Venmo |
SFTP Setup
IP addresses to whitelist
Your firewall must allow inbound connections from all seven Ingo Payments IP addresses:Information required from your team
Before production credentials are issued, provide the following to your Ingo integration manager:| Contact Details | SFTP Configuration |
|---|---|
| Company name | Host address |
| Name and title | IP address |
| Email address | Port |
| Phone number | Username |
| Date connectivity is needed | Password |
| File path / folder for delivery | — |