Preliminaries

Slate Payments is a built-in gateway and payment processor you can use instead of integrating Slate with an external processor.

Slate provides the ability to configure any particular payment gateway so that it only applies to particular payment types (aka payment account prompts), or particular rounds/periods, or both! You can use Slate Payments to collect an application fee or event payment, but still use another (external) payment provider to collect an enrollment deposit, if required. In these cases, carefully study the instructions in Step 3! If you have an existing payment integration, please see the last section of this article!

You can set up Slate Payments yourself, begin testing, and move to production use without Technolutions intervention or a support ticket.

Note: before embarking on this setup, you should have familiarized yourself with the general concepts of how Slate uses activities and interactions to facilitate the payment process.

Step 1 - Adding Permissions

Give a trusted user the "Payment Gateway Setup" permission. This is an exclusive permission, meaning it must be explicitly granted - it cannot be inherited from any role, including the Administrator role. 

We recommend restricting this permission as much as possible -- someone who has this permission can enter bank account data to route payments to a destination account. To help audit this process, we will automatically email your Slate security administrators whenever a new destination bank account is added.

Step 2 - Deposit Account(s)

Creating a Slate Payments Deposit Account

A deposit account represents the 'end point' of the payment process -- it is a holding account where the collected funds end up before being transferred to your external bank account.

To add a Slate Payments deposit account, go to the "Slate Payments Deposit Accounts" page (under Configurations on your Database page), then click "New Account". You'll be asked for a description, contact, banking, and verification information.

Note!

When you use Slate Payments, we will create a 'custom connect account' on our Stripe Connect payments platform on your behalf. At this time, we are not able to support linking Slate Payments with a previously existing, standalone Stripe account; the managed Connected Account must be used.

The use of Slate Payments requires agreement to the Stripe Terms of Service, but Technolutions manages the relationship with Stripe, and all confidentiality and data security provisions included in the Technolutions MSA continue to apply.

Important!

Please see the "Deposit Account Fields" section below for a detailed description of the individual fields!

After the initial 'save', you will be asked for further verification information, including the institution's official name, EIN number, organization representatives, etc. A Stripe-hosted form will handle this final account onboarding process. Additional verification issues or messages will be displayed there.

Organization representative

When setting up a Slate Payments account, a Slate administrator (or another designated representative) will need to enter personal information for an Organization Representative or Executive.

Providing personal information about an institution representative is required solely to allow the back-end payment processor can comply with regulations of the Office of Foreign Asset Control and "Know your customer" laws that prevent money laundering and other misuse. There are no responsibilities and there is no liability involved. The identity information is only used during the initial verification. The organization representative will not be contacted.

Note: This information is recorded at Stripe (on a Stripe page), not inside Slate. No Slate users have access to this information.

Stripe is now asking in many cases that someone act as representative who is an executive of the organization, to comply with the federal Beneficial Ownership Rule, which says "covered financial institutions must identify each beneficial owner by obtaining their name, date of birth, address, and identifying number (such as a social security number or other identifying number permissible under the CIP rule), and verify their identities."

Test Mode Setting

"Test Mode Accounts"

In most cases, the "test mode account" checkbox should be left unchecked, and you should use your real bank routing and account number (testing your setup in a 'test configuration' - see Step-3 below). A 'test mode account' can never be changed to production mode! It is only ever used for testing. Real deposit accounts can only be created in your production database, but they can be 'migrated' to the test environment (by provisioning a new Test environment) and used there in a 'test configuration', if desired!

A typical use case for using a 'test mode account' is when you need to see the process before deciding on adopting Slate Payments. A 'test mode account' can never be changed to production mode! It is only ever used for testing.

When creating a Test Mode account, you must use the following test bank account:

Routing:	110000000
Account:	000123456789

You still have to step through the Stripe-based account verification and supply all information about the organization and the individual representative (even if you use test information: https://stripe.com/docs/connect/testing#verification).

Please see the following section for further details on specific fields and options displayed during this step.

Details on Account Fields

The "Short Name" will appear on the applicant's credit card statement. Make this name as clear as possible to prevent disputed charges resulting from not understanding the payment. Include an abbreviated version of your school name.

The "Business Account Name" should be the official name of your institution and must match the name associated with the Tax ID you enter during the Stripe verification/onboarding process!

Contact Information

Banking and Payment Information

Step 3 - Connecting

Connecting payment account prompts to Deposit Accounts

Once you have created one (or more) deposit accounts, you'll need to connect it to a particular payment_account prompt value (or make it the default for all payments).

For application-scoped payments, you'll do this in the Application Editor. If you want to configure person-scoped payments (for example, an Event Fee payment for a person-scoped event), you'll need to open the editor by clicking the Person-Scoped Payment Configuration link on your database page (rather than by opening the Application Editor and selecting a round/period configuration).

First, select the application (round/period) configuration. If you have multiple applications configured, you'll need to perform this configuration step for each one (but you can use the same deposit account for multiple applications or payment accounts).

If you do not have any applications listed, you may need to use the Slate Template Library to add a Slate-hosted application file (base.xml file), even though you may not be using a Slate-hosted application otherwise.

Once you are editing a particular configuration, you'll see a list of application pages followed by a list of modules. In the list of modules, you should see a listing with a Part ID of "payment", followed by other listings for "payment_" plus various possible payment accounts (these will correspond to the payment_account prompt values that you have added to your database) To configure a default (or fallback) where all payments to go to the same deposit account, click the "payment" listing.

To configure Slate Payments for a particular payment account prompt value, click the listing for that account. For example, to configure the deposit account for application fees, click the "payment_Application Fee" listing (see also the note at the end of this article).

(Note: to add new payment accounts, just add new prompt values, with a key of "payment_account".)

Once you click the listing, you will see the module details and should click "Payment Providers" on that page.

Test Configuration

An edit pop-up will appear, where you'll see a drop-down for Payment Provider. To configure Slate Payments and connect a Deposit Account, initially select "Slate Test". Once you pick "Slate Test", you'll see a drop-down with a list of the Slate Payments Deposit Accounts that you created in Step One. Select the appropriate deposit account, and click Save. You've now enabled Slate Payments in a test configuration and you can simulate the collection of test payments.

Payment Provider - Slate Test

Note the other options in this pop-up window and decide whether to allow checking account and card payments. Finally, consider configuring custom dispute evidence text that will be sent to the payer's bank  or card issuer whenever a payment of this type is disputed by a user.

Step 4 - Testing

To test your payment configuration, add a Payment Due activity in an appropriate payment account to a test application. You can do this manually, or (even better) you can set up one or more payment rules and test that part of the process as well. (For example, create a rule that adds an Application Fee Payment Due activity when the application is submitted, and then submit an application for a test applicant.)

Once you have a test applicant with a Payment Due activity, go to their Application Status page and click the Submit Payment link (or click the payment link in the activity). This will take you to the payment page.

While your payment configuration is set to "Slate Test", you can make payments using test credit cards or bank accounts.

Test Credit Cards

You can test a declined card by using the Visa number 4000000000000002. For all test credit cards, you may enter any expiration date in the future, and any card verification code you like.

To test ACH/Check payments, use the routing number 110000000, and the account number 000123456789. To test a failed check payment, use the account number 000222222227.

When a payment succeeds, you should see a Payment Received activity on the student account, and the "Submit Payment" link should no longer appear on the status page.

Step 5 - Production mode

Moving to Production mode

When you have verified that payments are working as expected, you can switch one or more of your Slate Payments Deposit Accounts to be used in production mode. In the Application Editor (or Person-Scoped Payment Configuration), simply repeat the operations from step three, but this time select the payment provider "Slate" instead of "Slate Test".

As part of your go-live planning, you should make sure you have reviewed the payment system emails and made any changes that you need.

Payment Provider - Slate

You may wish to conduct a real-money test transaction, just to verify that everything is operating as expected and that the funds arrive in the correct account.

Setting Up Notifications

Setting up system notifications for Slate Payments

Slate will send emails as they relate to Slate Payments based on a set of triggers. Many of these mailings can be customized, and some emails need to be configured using Deliver in order to send. This System Emails for Slate Payments article will detail the content of automatically configured mailings, and the cases in which automatic Slate Payments emails can be customized.

Migrating to Slate Payments

Migrating (fully or partially) from an existing external payment integration to Slate Payments

If you're currently accepting payments through another external provider, but you want to test Slate Payments (for some or all payment accounts) before going live, you can either:

1. Set up the Deposit Accounts as explained in Step-2 above, refresh your test environment, and then complete Step-3 in your test environment, or else

2. Create a separate test payment account prompt value (e.g. "Test Fee"), link that prompt value to Slate Payments (as per Step-3) while leaving the other provider live, and then switch later when you're ready to go live with Slate Payments.

Before moving forward -- Deactivating your previous payment integration (for testing or production) may involve renaming files or deleting configuration sections from existing files. Each external payment integration setup is different. We will evaluate what work is required to de-activate the old components. Please open a support ticket in the "Slate Payments" category!