PeopleSoft Campus Solutions

This guide documents Meadow's bi-directional integration with PeopleSoft Campus Solutions. It covers data extract, DNS and SSO, and payment postback.

1. Solution Overview

1.1 What Is Meadow?

Meadow is a modern, mobile student accounts receivable (A/R) solution helping hundreds of colleges and universities recover more A/R and re-enroll more students by automating the entire accounts receivable and pre-collections process. The platform enables schools to:

• Notify students of outstanding balances
• Offer payment options and payment plans
• Automatically follow up on unpaid balances
• Post payments directly back into the SIS

1.2 Integration Scope

Meadow's PeopleSoft integration is file-driven, using SFTP to transfer CSV and flat files on a regular cadence. The integration includes bi-directional data flow between PeopleSoft and Meadow.

PeopleSoft → Meadow

• Academic calendar data (terms)
• Student profile data
• Student charge and credit data (account activity)

Data is extracted from PeopleSoft (via SQL or PeopleSoft Query), written to CSV, and uploaded to Meadow's SFTP server.

Meadow → PeopleSoft

• Payment post-back

Meadow writes a daily .dat payment file formatted for the Student Financials SF External File Load process. Real-time, API-based post-back is also offered.

No software is installed inside PeopleSoft. The school controls how data is extracted and how files are moved. Meadow provides file specifications, an SFTP endpoint, and optional template scripts.

1.3 Implementation Timeline

Typical implementations complete in 4 to 6 weeks with four steps:

1. Configure networking, DNS, and SSO.
2. Build and schedule the three PeopleSoft extracts (academic calendar, students, charges) and automate the SFTP transfer.
3. Meadow validates the extracted data against the school's reports.
4. Configure and test payment post-back.

2. Data Imports Overview

Meadow requires several types of SIS data to identify student balances and communicate with students.

• Academic calendar data. Academic terms and term start and end dates. Lets Meadow determine billing timelines and show the correct term descriptions in the app.
• Student data. Demographic and enrollment information used to communicate with students, identify and report on student accounts (for example, aging reports), associate payments with the correct student record, and build population segments for personalized communications.
• Charge data. Every financial transaction that makes up a student's balance: tuition, fees, and other charges; deposits; financial aid, including anticipated aid; refunds; and payments. Used to calculate balances, display detailed bills, and power reporting.

3. Data Extraction and Delivery

3.1 Extraction Options

Each of the three files can be produced using either approach below. Schools may mix approaches (for example, PeopleSoft Query for students and the academic calendar, and SQL for charges).

• Raw SQL. A SQL script, run against the PeopleSoft database with a read-only account, selects the required rows and columns directly from the Campus Solutions tables. This is typically the most flexible option and the easiest for Meadow to help tune.
• PeopleSoft Query. PeopleSoft Query (often called PS Query) is PeopleSoft's built-in reporting tool. Queries are built in Query Manager against the PeopleSoft record definitions without writing SQL, can be run on demand in Query Viewer, and can be scheduled through Schedule Query and Process Scheduler to produce output on a recurring basis. This option suits schools where IT prefers not to grant direct database access, or where the Student Finance office already maintains queries for similar extracts. Query output must be saved as CSV with the column order and formatting in the file specifications.

Meadow can supply reference SQL for each file. Schools using PeopleSoft Query can use that SQL as a guide to the records and fields involved.

3.2 Upload Automation

Files should be generated and uploaded to Meadow's SFTP server on a regular cadence. For example:

• Academic calendar: daily
• Students: daily
• Charges: every 30 minutes or as quickly as practical

The school chooses how to automate the transfer:

• Meadow template scripts. Meadow can supply template PowerShell or Bash scripts that connect to the database, run the queries, compress the output, and upload it to SFTP. The school schedules the script with Windows Task Scheduler, cron, or any preferred job scheduler. The scripts take a parameter for which job to run: students, academicCalendar, or charges.
• School middleware or iPaaS. Schools with existing integration tools (an iPaaS, a managed file transfer tool, etc.) may use that instead. Any tool that can use SFTP with SSH-key authentication will work.

Meadow engineers are alerted when files stop arriving on the expected cadence.

3.3 SFTP Connection

Meadow provides a dedicated SFTP account per school and environment. Your Meadow contact provides the host, username, and directory root. The folders under that root, and the files that go in each, are listed in section 3.4.

Why SSH keys for SFTP

The PeopleSoft integration transfers files with key-based authentication. Compared with passwords, SSH keys are hard to guess, phish, or brute-force, and can be protected with a passphrase. The school keeps the private key on the server that runs the scheduled jobs and sends Meadow only the corresponding public key.

3.4 File Naming and Cadence

Meadow's file naming patterns are not strictly required, but they are strongly recommended. Meadow identifies files by folder, so folder names must be exact. A leading ISO-8601 timestamp keeps files unique and easy to sort.

• [school] is the school's short name, typically the root of the school's domain.
• Inbound CSV files should be compressed as .zip before upload. Meadow unpacks them automatically.
• Meadow currently reads columns by position, not by header name. A header row with the correct field names is still required.
• Dates in the CSV files use ISO-8601 (yyyy-MM-dd).
• nnnn in the payment file name is a sequence number that increments within a day. Multiple files per day are rare.

4. File Specifications

Column layouts for the three inbound files are on the shared file pages. Choose PeopleSoft in the SIS picker at the top of each page to show the recommended PeopleSoft record for each column.

• Academic calendar file
• Students file
• Charges file

The payment file Meadow writes back is specified in section 4.1. It is a fixed-width text file, not a CSV.

4.1 Payments

A daily file of payments and reversals that Meadow writes to the school's SFTP account. The school downloads it and loads it into PeopleSoft with SF External File Load (see section 6.1). Each row is one payment applied to one term. A payment that covers several terms produces one row per term.

This is a fixed-width .dat text file, not a CSV. There is no header row and no delimiter. Each field occupies a fixed number of characters and is padded with spaces.

Example

0012345678  123.4580000001002942421002262267N
0012345678  123.4580000001002942421005262267Y

The first line is a $123.45 card payment on 10/02/26 applied to term 2267. The second line reverses it on 10/05/26.

5. Networking and SSO Configuration

School-specific DNS values are provided by your Meadow contact.

5.1 DNS Configuration

Email records. Meadow sends email through SendGrid. Your Meadow contact provides the CNAME records to add for link tracking, the sending subdomain, and DKIM.

Meadow application DNS. Delegate the pay subdomain to Meadow's nameservers with four NS records. Meadow provides the nameserver values. DNS propagation can be verified with a public DNS checker.

5.2 Email Allow-Listing

In rare cases an email gateway blocks Meadow's messages. If so, your Meadow contact provides the sender IP addresses to allow. If you use an Exchange transport rule that blocks external senders spoofing your domain, add an exception for messages that pass DKIM for your domain.

5.3 SSO Configuration

Meadow supports SAML 2.0. Map the EmployeeId claim to the student's EMPLID. Claim names are case-sensitive. See SSO for more detailed steps.

6. Posting Back Payments

PeopleSoft remains the source of truth for student account balances. A payment is not complete until it has been successfully posted back to PeopleSoft.

Meadow supports two post-back methods: daily file and API. API-based postback is preferred because it sends payments back to the SIS in seconds but requires more effort to implement.

6.1 Daily Payment File (SF External File Load)

Meadow writes a fixed-width .dat payment file to /payments/unposted/ on the school's SFTP account. The file is formatted for the delivered Student Financials SF External File Load process (SFPRGPLD), so no PeopleSoft customization is required.

How files are generated

• One file per business day, generated after the close of the prior day. No files are generated on weekends.
• Monday's file includes Friday, Saturday, and Sunday payments.
• No file is generated on days with zero payments.
• Each file contains only new payments since the previous file. The payment date on each row preserves the original payment date.
• Returns and refunds are written as positive amounts with the reversal indicator set to Y.
• A single payment may be split across multiple terms, oldest first, if the student owes for several terms.

How files are loaded

1. The school's scheduled job downloads the file from /payments/unposted/ and places it where PeopleSoft can read it.
2. The job moves the file from /payments/unposted/ to /payments/posted/ on SFTP.
3. Student Finance runs SF External File Load (Student Financials, Charges and Payments, Group Processing, External Files), selecting the External File Layout configured for Meadow. The process creates a group in Group Data Entry.
4. Student Finance runs Group Post to apply the group to student accounts.

Meadow alarms if files sit in /payments/unposted/ longer than expected.

Before go-live, Student Finance needs to:

• Create one or more item types for Meadow payments. These can differ by card type.
• Create an External File Layout (Set Up SACR, Product Related, Student Financials, External File Layouts) matching the payments file in section 4.1.
• Decide whether loaded groups post automatically on a schedule or are reviewed and posted manually.

6.2 Real-Time API Post-Back

As an alternative to the daily file, Meadow can post each payment to PeopleSoft in real time through an API endpoint the school exposes (for example, a PeopleSoft Integration Broker service operation, or a middleware endpoint that writes to Student Financials). Payments then appear in PeopleSoft within seconds of the student paying, and the /payments/ SFTP directories are not used.

Contact Meadow's integration engineering team to discuss API post-back.

6.3 Testing and Validation

Meadow works with the bursar's office to test in both staging and production.

Testing in staging

1. Meadow generates sample payment files from its staging environment.
2. Student Finance loads the files into the PeopleSoft test environment and verifies that the payments post correctly.
3. Meadow verifies that the payments appear in new charge files (round trip).
4. If issues arise, adjustments are made before moving forward.

Final validation in production

1. Meadow runs a controlled test in production by making small donations, with real money, to real students to confirm that payments process, funds post to student accounts, item type mappings work as expected, and funds reach the school's bank account.
2. The billing office confirms that the transactions are reflected correctly in PeopleSoft.
3. Once validated, Meadow is ready to go live.