- 15 Nov 2023
- 8 minute read
- Print
- DarkLight
- PDF
Charging Payments in Slate Using Interactions and Activities
- Updated 15 Nov 2023
- 8 minute read
- Print
- DarkLight
- PDF
The first step in collecting a payment is indicating that a prospect or applicant owes an amount, for a particular payment type (e.g. an event payment, or an application fee). This is done by either adding an activity to the application record, or adding an interaction to the person record. (If you are using our built-in Slate Payments product, you can also charge payments for a dataset record using the form payment widget. For all other payment processors, only person or application records are supported.)
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.
Please Note
Activities with a Payment code should only be used if you are collecting payments through Slate, as they will result in applicants seeing payment notifications. Do not add Payment activities if you are not collecting payments through Slate (or use the Service Desk to contact us if you think this may be appropriate for you).
Also note that the Payment activity code is a special code used for this purpose only and as such should never have subcodes added. Different types of payment activities can be indicated using the Payment Type.
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.
Person-Scoped Payments
Thus far, this article has been discussing payments charged to applicants, and indeed these are the majority of Slate payments. However, there are scenarios in which payments are charged to people who are still at the inquiry stage. The most common example is an event fee for an event designed for people who are not yet applicants.
Payments for inquiries are essentially the same as applicant payments, except that instead of using application-scoped activities to record payment due, payment received, or payment waived, we will use person-scoped interactions. To add a payment due for an event, you can make a rule that runs on form submission to add a Payment Due interaction.
The big difference is that, because they are not yet an applicant, you are unable to communicate with them through their applicant status page. Instead, you must communicate with them through a confirmation page or email to direct them to make a payment. When you create a communication for a form or event, a Form-Payment merge field will be available. Adding this merge field to your communication will insert a payment link that the registrant can use to initiate a payment. From that point, the rest of the payment process will be the same as described earlier.
Note that the link is based on the ID of the Payment Due interaction, so if the rule was not operating when the registration was submitted, the link will not function.