You can create interactions on a person record (or activities on an application record) to indicate that a payment is due. You can do this manually, or it can be created through a rule, or through a form submission. Of course, adding payment interactions or activities does not by itself initiate a charge or payment process.

✨ Tip

Slate Payments, our native payment processor, gives you additional features, like actually collecting payments directly on a form or event using the form payment widget.

Before you begin

An interaction or activity on a record records an event having taken place. Interactions can be the product of automations, and can themselves trigger automations.

Configure payment accounts

Make sure that the necessary payment accounts are configured. A payment account is a prompt value with the special-use system key of payment_account.

Default payment accounts include Application Fee, Enrollment Deposit, and Event Payment. For example, the prompt settings for Application Fee are:

• Status: Active

• Key: payment_account

• Value: Application Fee

Access payment accounts in Database > Prompts, then select payment_account from the list.

Create additional custom payment accounts for any other fee types you need. To make things easier for you down the line, try to keep the number of payment accounts as small as possible.

To create a new payment account:

1. Select New Prompt in the payment_account prompt overview page.

2. Configure the following settings:

   • Status: Active

   • Folder: Select an existing folder, or select Other to create a new one.

   • Value: Enter the applicant-facing name of the payment account.

   • XML Configuration tab: If you are collecting payments in a currency other than US dollars, configure a non-default currency value by adding an XML configuration, otherwise leave this section blank. This adjusts the displayed currency in the activities/interactions within Slate.

3. Select Save.

Currencies

By default, payment activities/interactions will display, and payments will be charged in US dollars (USD), but a particular payment account can be set to use a different currency. To do this, add the following code in the XML section of the prompt configuration:

<p>
  <k>currency</k>
  <v>CHF</v>
</p>

📝 Note: When a payment account is attached to a particular activity or interaction, it is connected only by the name of the account (the string value), not the prompt’s GUID. So, if you change the name, existing activities will not change. Only change names of payment accounts between seasons, during a time when no payments are outstanding.

New payment accounts are available in payment activities.

Select the force-refresh link in All Prompts to refresh the prompt cache and access new prompts immediately after creation.

With accounts out of the way, we can move on to creating payment interactions or activities.

Step 1: Adding a Payment Due interaction / activity

You can add application-scoped or person-scoped payment activities to a person’s record.

• To add a Payment Due activity to an applicant’s application record:

  1. On a person record, select an application tab.

  2. Under Activities, select New Activity. A pop-up appears.
     

• To add a Payment Due interaction to a person record:

  1. On the person record, select the Timeline tab.

  2. Select New Interaction. A pop-up appears.
     

Then, configure the following settings:

• Code: Payment

• Date: Can be pre- or post-dated. Defaults to the current date and time.

• Payment Type: Payment Due

• Payment Amount: Enter the payment amount (in the configured currency).

• Payment Account: Select the appropriate payment account from the list.

• Expires Date: Set an optional date after which access to the payment activity expires.

Select Save.

Calculating the Payment Due amount with rules

As shown in the previous section, the Payment Due amount can be added manually, but more often they are added automatically by rules. A rule that creates a Payment Due activity always indicates the payment account and the payment amount.

For example, a rule might add an application fee Payment Due activity 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.

You can create multiple rules for a given payment type, using filters to distinguish between applicant groups. This lets you to charge different amounts to different applicants.

For example, you might charge a different amount for international applicants versus domestic applicants, or for applicants to a particular program.

Examples: Application Payment Due Activities or Enrollment Deposit Payments

Calculating the Payment Due amount with the payment form widget

Another option for creating a Payment Due activity or interaction is to use the payment form widget.

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.

While the payment widget can be used to actually collect a payment if you use our built-in Slate Payments product, any institution using an external payment processor can use the form payment widget to calculate a payment due amount (and create the relevant due interaction or activity after form submission).

📖 Further reading: Payment form widget

If you use Slate Payments, you can charge payments for a dataset record using the form payment widget. For all other external payment processors, only person or application records are supported. If you're interested in Slate Payments instead of—or in addition to—integrating with an outside vendor, see Slate Payments Setup.

If you are using an external payment processor, be aware of the limitations to external payment processors.

Step 2: Sharing the payment link with the person or applicant

Sharing the Payment Link in a Deliver Mailing or Event Communication

Displaying the Payment Link in a Portal (Example from an Application Status Portal)

Step 3: Creating Payment Received and Payment Waived activities / interactions

Payment Received activities (or interactions) will be automatically added by Slate when the payment is initiated from Slate (with a proper/supported integration) and the payment processor successfully notifies Slate that an online payment has been successfully processed. If a payment is received outside of Slate, for example via a check sent in the mail, the Payment Received activity will need to be manually added to the record.

Payment Waived activities can be added to reduce or eliminate the amount due. These can also be added manually, for example, if an applicant makes a special request due to financial hardship. However, similar to Payment Due activities, these can also be added by rules.

Follow this Example: Application Payment Waivers

📝 Note

• The amount that an applicant owes for a given payment account is calculated by adding up all of the Payment Due amounts for that account, and subtracting all the Payment Received and Payment Waived amounts. If an applicant has the full payment amount 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).

• Most external payment providers do not support a partial payment (on their payment page) when you indicate the amount.

• 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.

Additional Payment Information

Application-Scoped Payment Due Activities

It is important to note that activities with a payment code should only be used if you are actually 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.

Payment activity code is a special-use system code used for this purpose only and should never have subcodes added!

Display to the Applicant

If an institution is using the default 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 Portal, then the payment due notification will appear if the Payment status portal widget is included in the relevant portal view.

Note that, if configuring the default Status Page through the Application Editor, you have the option to enable or disable the display of the payment notification. If using a custom Application Status Portal, you can simply include or not include the Payment status portal widget in the portal view (and/or use filters to display the widget).

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

Person-Scoped Payment Interactions

There are many scenarios in which payments need to be connected to the individual, because there may never be an application or the context/scope of application is not applicable to the situation at-hand: people who are (i) still at the inquiry stage, (ii) who are donors, (iii) current students, or (iv) who are simply guests and not applicants. One common scenario is an event fee. Instead of using application-scoped activities, you would now use person-scoped interactions which are visible/accessible on the Record’s Timeline.

To add a ‘payment due’ for a person-scoped event form (with an event fee), you can make a rule that runs on form submission to add a Payment Due interaction, or use the payment widget to calculate the amount due. If you are using Slate Payments, you will simply use the payment widget to collect the payment within the form and Slate will automatically add the payment due interaction as part of the payment processing and form submission (and you won’t have to worry about the following steps).

Display to the Person

Since person records are not yet an applicant (or never will be), you are unable to direct them to their default Applicant Status Page. Instead, you must communicate with them through the form’s confirmation page or via email to direct them to make a payment on the payment page. 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. Note that this merge field is always pointing to your Production environment (never to a Test environment). From that point, the rest of the payment process will be the same as described earlier.

Note that the link is referring to the ID of the Payment Due interaction, so if the rule was not operating when the registration was submitted, the link will not function.

Payment Refunded Activities

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

Important!

Manually adding a Payment Refunded activity does not trigger a refund: it only records that a refund was made outside of Slate. When you use an external payment processor, the refund must be initiated in your payment system of record.

If you are using Slate Payments and want to initiate a refund (and have the relevant permission to do so), there's a link in the Payment Received activity.

📖 Further reading: Refunds for Slate Payments

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 – Deposit Paid 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.

Follow this Example: Add Deposit Paid Decision