Payment Due Activities

Payment information for applicants in Slate is represented by activity entries on the application record, with an activity code of Payment. Initially, the record will be given a Payment Due activity to indicate that the applicant owes money in a particular payment account (such as application fee or enrollment deposit). Any Payment activity can be added to a student record manually (by clicking New Activity), but this will typically be used only for testing or one-time exceptional situations.

More commonly, Payment Due activities will be added through the use of rules. For example, a rule might be created that will add an application fee Payment Due when the application is submitted, or a rule might add an enrollment deposit Payment Due when an applicant submits an admission reply form and indicates that they plan to enroll. A rule that creates a Payment Due activity will always indicate the payment account and the amount. You can create multiple rules for a given payment type, using filters to distinguish between applicant groups; this can allow you to charge different amounts to different applicants. For example, you might charge a different amount for international applicants, or for applicants to a particular program. 

Calculating the Payment Due amount

The usual way of determining the Payment Due amount is by using a rule or set of rules. For example, if there are a few different possible deposit amounts for different types of applicants, you could create a series of rules in an exclusivity group to add the correct Payment Due.

Another option for creating a Payment Due activity or interaction, however, is to use the payment widget in a form. While the payment widget can only be used to actually collect a payment if you use our built-in Slate Payments product, any institution can use the form payment widget to calculate a payment amount. The form payment widget can use a calculation formula to determine the amount based on other fields within a form. For example, in an enrollment reply form, you might ask whether the applicant plans to live on campus or not, and calculate the deposit amount based on the answer.

Payment Accounts

While the most commonly used payment accounts for applicants are Application Fee and Enrollment Deposit, Slate allows you to create any number of additional custom payment accounts you need. A payment account is actually just a prompt value with a special-use system key of payment_account.

• Status - Active

• Key - payment_account

• Value - Application Fee

Any new payment accounts that are created by adding new prompt values will be available to use in payment activities (for immediate use, you may have to refresh the cache). In general, since you will be referring to these payment accounts in rules, filters, etc., you should try to keep the number of accounts as small as possible.

Note that when an applicant sees a Payment Due notification, they will see the name of the payment account, so name any new payment accounts in ways that will make sense to a prospect or applicant. Also note that when a payment account is attached to a particular activity or interaction, it's only using the name of the account (the string value), not linking to the actual prompt GUID. This means that, if you change the name, existing activities will not change. For this reason, we recommend only changing the names of payment accounts in between seasons, during a time when no payments are outstanding.

If you are collecting payments in a currency other than US dollars, you will need to configure a non-default value in the payment_account prompt record (by adding an XML configuration). This will adjust the currency display in the activities/interactions inside Slate.

Payment Received and Payment Waived Activities

The flip side of a Payment Due activity is an activity to tell us that the payment is completed. There are two such types of activities: Payment Received, and Payment Waived. The amount that an applicant owes in a given payment account is calculated by adding up all of the Payment Due amounts in that account, and subtracting the Payment Received and Payment Waived amounts.

Typically, a Payment Received amount will complete a payment – most payment providers do not support a partial payment when you indicate the amount. Payment Waived activities can be added to reduce or eliminate the amount due. Note that Slate will never display a negative amount due—if the Payment Waived amount is greater than the Payment Due amount, no amount due will be shown. As a result, you can add Payment Waived activities before adding the corresponding Payment Due activities, if that fits your process better.

Payment Received activities will be added by Slate when a payment processor indicates that an online payment has succeeded. However, they can also be added manually; this will typically be done when a payment is received off-line, for example via a check sent in the mail. Payment Waived activities can also be added manually (for example, if an applicant makes a special request due to financial hardship) but are often added by rules (for example, if you want to waive some or all of a payment for certain applicants). If an applicant has all of a payment waived, they will never see the Payment Due notification, but they will see a Payment Waived activity in their recent activity list (on the status page).

Payment Refunded Activities

If a payment is refunded outside of Slate and you want the applicant to owe the fee again, you can manually add a Payment Refunded activity to the record, which will counter the Payment Received activity.

Note that adding a Payment Refunded activity does not trigger a refund; it is merely meant as a way to record that a refund was made outside of Slate. Using an external payment processor, the refund will always need to be initiated in your payment system of record!

If you are using Slate Payments and want to initiate a refund, there's a link in the Payment Received activity. See the separate article covering refunds for Slate Payments for more details.

Display to the Applicant

If an institution is using the default applicant status page, then the payment due notification and payment link will automatically appear whenever an applicant owes money. Whether an applicant owes money is determined by adding up all Payment Due activities in a given payment account, and subtracting any Payment Received or Payment Waived activities in that same payment account. If an institution has a custom status page (or portal), then the payment due notification will appear if the Payment status widget is included in the status page (or relevant portal view).

Note that, if configuring the status page through the Application Editor, you have the option to enable or disable the display of the payment notification. If using the Status Portal, you can simply include or not include the Payment status widget in the portal view.

Additionally, if the Recent Activity widget is included in the status page (or portal view), it will display recent payment activities such as a Payment Received or Payment Waived activity.

Rules Triggered by Payments

The action of adding a payment received activity to a student record is considered an application update, so you can create rules that will take actions based on a payment being received. A common scenario is to add a decision of Admit – Matriculate to an applicant record once the applicant has paid their enrollment deposit. This would simply be a rule that runs on application update which uses the Payment Complete filter to select applicants and add a new decision. 

Note that, for a payment to be "Complete", it must be charged and then fulfilled. In other words, if you have a Payment Due and a matching Payment Received, or a matching Payment Waived, then the payment is complete. For this reason, if certain applicants should not be charged, the recommended approach is to give them a Payment Due activity and then also a Payment Waived activity in the same amount.