Preliminaries
Slate Payments is a built-in gateway and payment processor you can use instead of integrating Slate with an external processor.
You can set it up yourself, begin testing, and move to production use without Technolutions intervention or a service request. Please review and follow the steps outlined below.
Note: before embarking on this setup, you should have familiarized yourself with the general concepts of how Slate's activities and interactions are used to facilitate the payment process.
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 use another (external) payment provider to collect an enrollment deposit. 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!
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.
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.
"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. 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 example of a 'test mode account' is when you need to see the process before 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 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!
| Option | Description |
|---|---|
| Email to use for payment issues | An email address will be made available to payers for help. You will most likely want this to be someone in your office, as questions can involve your processes (e.g., waivers, deposits). |
| Phone number to use for payment issues | A number that will be made available to payers for help. Again, this should be someone who can assist with procedural questions. |
| Email to use for notifications | Used for disputed charges, issues with transfers into your account, and verification problems. It could be someone in a financial office. |
| Option | Description |
|---|---|
| Routing and Account Numbers | Please check these numbers carefully. If you have to update the information at a subsequent time due to a previous typo or an actual change in the account number you intend to use, please edit/enter the values for both fields before saving the information. They have to be updated as a pair. |
| Currency | Selected currency must be a supported currency for the country where the bank account is located. If you are collecting payments in a currency other than US dollars, you'll also need to configure that in the payment_account prompt (by adding XML to the prompt -- please submit a service desk request for assistance). |
| Short Name | In the banking information, you can select a short name to appear on the transfer. The bank transfer system ("ACH") allows us to send a short string called a statement descriptor with each transfer. Different banks display this in different ways (and some don't display it at all), but if your bank supports it, a descriptor can help distinguish transfers from different sources. |
| Transfer Schedule | The payment processor will collect the funds as they come in and transfer them into your external bank account in bulk. This can happen daily (on a rolling two-business-day basis in the USA, longer in other countries), once per week, or once per month. You'll be prompted to choose which day if you select weekly or monthly. The first transfer to your account can take up to 7 days to post. |
| Automatically add processing fee to amount |
Note:You should only use this option if your deposit account is US-based! For a U.S. institution, transaction fees are the same for credit cards originating in any country. Taking a card payment from an international bank, a US-based institution will still pay the same fee. This is not true for other countries! |
| Allow Partial Payments | By default, the user can only pay the exact amount due. If you select this option, the payment page will display a link to "Edit Amount" allowing the payer to change the amount to a smaller amount so that they only pay part of the amount due. An applicant's status page will show the balance due. We won't enable them to edit the amount to pay more than the amount due. Note that if you have also selected "Automatically add processing fee to amount" the fee will change to reflect the amount being paid. (Note: This option will only work on the payment page; it is not a workable solution when the payment widget is used on a form.) |
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.
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
| Card Type | Number |
|---|---|
| Visa | 4242424242424242 |
| Visa | 4012888888881881 |
| Visa (debit) | 4000056655665556 |
| MasterCard | 5555555555554444 |
| MasterCard (debit) | 5200828282828210 |
| MasterCard (prepaid) | 5105105105105100 |
| American Express | 378282246310005 |
| American Express | 371449635398431 |
| Discover | 6011111111111117 |
| Discover | 6011000990139424 |
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 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:
- 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
- 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 service request in the "Payment Integration" category!