Food Provider

We can send all request bodies serialized as application/json in addition to application/x-www-form-urlencoded. We will not send any other file format.

Implemented via web server:

Two resources must be publicly accessible:

Balance Request

This solution is ideal for getting your balance into the Food Service Section of the Payment Center. When the parent logs into our system, SchoolPay calls your Food Service Provider server with a password and a student ID, and your server returns the users balance. Parents can then see their real-time balance with no cache/lag. This results in reduction for both sides’ resources. We only request from you that which we need. Balance request requests multiple students balances and PH’s, to reduce “chattiness” burn time.

Requests a standard form vector of student ID’s, a number of days, and a shared secret, and receives those student’s current food service balances, and purchases made in those number of days.

Incoming Request 
POST /balance HTTP/1.1
Host: your-server.com
Accept: application/json
Content-Type: application/x-www-form-urlencoded

secret=xxx&days=5&ids[1]=1&ids[2]=2552

Note: Days calculation should go back to midnight on that day. However, you can send an AfterDate equal to the oldest purchase history returned. SchoolPay will use the AfterDate value to determine which purchases to delete before inserting all purchases in the response.

Your Response 
HTTP/1.1 200 OK
Content-Type: application/json
Content-Length: 534

{
    "Students":[{
        "StudentID":"1",
        "FamilyID":null,
        "StudentSite":"24",
        "VendorName":"Vendor",
        "BalanceDate":"2010-02-21T10:58:12-05:00",
        "Balance":12.65,
        "Purchases":[
            {"ID":415334,"Item":"Lunch","Amount":2.4,"Date":"2010-02-21T10:58:12-05:00"},
            {"ID":418158,"Item":"Breakfast","Amount":1.1,"Date":"2010-02-22T08:04:00-05:00"},
            {"ID":418935,"Item":"Lunch","Amount":2.4,"Date":"2010-02-22T10:57:26-05:00"},
            {"ID":421904,"Item":"Breakfast","Amount":1.1,"Date":"2010-02-23T08:02:03-05:00"},
            {"ID":421905,"Item":"Milk","Amount":0.35,"Date":"2010-02-23T08:02:03-05:00"},
            {"ID":422572,"Item":"Lunch","Amount":2.4,"Date":"2010-02-23T10:57:24-05:00"}
        ]
    }],
    "AfterDate":"2018-02-21T15:45:06-05:00"
}

Note: ALL dates should be formatted ISO 8601 combined date and time. If not timezone is present, central time will be assumed, but this can lead to gaps in purchase history, as we will delete all purchase history after AfterDate, sending a time relating to an earlier time when parsed in central time can lead to hour-ish gaps.

Note: If you do not want to write to purchase history, simply return an empty array []. It is recommended that you calculate a PH start date and return it, however, as it would give you less work to do in the future if you want to add PH. Adding PH requires no work on SchoolPay’s end, as we are always expecting PH.

Note: Students at multiple sites should be returned as separate students. SchoolPay has support for students having different balances at differnet schools and will reconcile them correctly.

Note: If a student shares a balance with another student, you should return a primary key to that relationship via FamilyID. SchoolPay will treat this balance as a single resource between the two students. However, you should return all students asked for. SchoolPay does not create a family account for purchase history, so it is recommended that you send PH on the individual student that purchased the item instead.

Make Deposit

This solution is ideal for making a deposit to your Food Service account. When a deposit is made, MPN sends student ID, password, and amount to district or Food Service Vendor and your District/Vendor sends back success message. This is beneficial because it provides quicker fund availability (Can be immediate), and because there are lighter requirements on district’s side to load in real-time vs. from a process.

This solution requests a shared secret and array of deposits. The deposit contains student ID, amount, and transaction ID. The response is an array of statuses back, one for each post, including the ID of the row represented by this deposit. The response will also convey the capabilities of the endpoint, for example if it can prevent duplicate deposits or not.

Incoming Request 
POST /deposit HTTP/1.1
Host: your-server.com
Accept: application/json
Content-Type: application/x-www-form-urlencoded

secret=xxx&days=5&deposits[1][id]=1&deposits[1][amount]=10.00&deposits[1][txn]=12345&deposits[2][id]=2&deposits[2][amount]=10.00&deposits[2][txn]=12346
Your Response 
HTTP/1.1 200 OK
Content-Type: application/json
Content-Length: 184

{
    "Status":"Success",
    "DuplicatePreventionEnabled":"yes",
    "Deposits":[
        {
            "StudentID":"1",
            "FamilyID":null,
            "StudentSite":"24",
            "Amount":"10.00",
            "Deposited":"yes",
            "TransactionID":"12345",
            "PurchaseID":425896,
            "Reason":""
        },
        {
            "StudentID":"2",
            "FamilyID":null,
            "StudentSite":"24",
            "Amount":"10.00",
            "Deposited":"yes",
            "TransactionID":"12346",
            "PurchaseID":425897,
            "Reason":""
        }
    ]
}

Note: The status field is what SchoolPay looks at to determine if the entire transaction needs to happen again. There are three values, Success, meaning the deposit worked fine, Queued, meaning that the deposit will go through eventually, but it does not take effect immediately on the balance, and any other response (Failure is a good choice) indicates that the transaction should be retried. Sending capabilities for duplicate prevention and values for Deposited can prevent SchoolPay from making duplicate deposits. Combination

Go Live