Slate Payments is a built-in gateway and payment processor that can be used instead of integrating Slate with an external processor (or alongside another external processor for a given set of payment account prompts).
You can set it up yourself and begin testing, or move to production use, without the need for Technolutions intervention or a service request. Please review and follow the steps outlined below.
Note: prior to embarking on this setup you should have familiarized yourself with the general concepts of how activities and interactions are used in Slate 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 may want to 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!
Step 1 - Adding Permissions
Give a trusted user the "Payment Gateway Setup" permission. This is an exclusive permission, which means that 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 send an email to your Slate security administrators whenever a new destination bank account is added.
Step 2 - Deposit Account(s)
Creating Slate Payments Deposit Account(s)
A deposit account represents the 'end point' of the payment process -- it is a holding account where the collected funds end up prior to being transferred to your bank account. In order to set up a deposit account, you must have the "Payment Gateway Setup" permission.
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 description, contact, banking, and verification information.
When you use Slate Payments, we will create a 'custom account' on our Stripe Connect 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.
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 official name of the institution, EIN number, organization representatives etc. This final account on-boarding process will be handled by a Stripe-hosted form. Verification issues or messages will be displayed there.
In most cases, the "test mode" checkbox on the account should be left unchecked, and your real bank routing and account number should be used. 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.
Only if you need to test Slate Payments before you have actual bank information, should you contemplate creating a "test mode" account to use temporarily. When creating a Test Mode account, you must use the following test bank account:
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).
If you are already confident that you will use Slate Payments and you have your real bank account information available, you should use your real bank information to set up your deposit account!
The typical use case for a 'test mode account' is when you need to see what the process looks like before you decide to adopt Slate Payments. A 'test mode account' can never be changed to production mode! It is only ever used for testing.
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 what the payment is for. Include an abbreviated version of your school name.
The "Business Account Name" should be the name of your institution and should match the name associated with the Tax ID that you enter during the Stripe verification/on-boarding process.
|Email to use for payment issues||An email address that will be made available to payers for help. Most likely you will want this to be someone in your office, as questions may 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, verification problems. Could be someone in a financial office.|
|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 make sure to edit/enter the values for both fields before saving the information. The have to be updated as a pair.|
|Currency||Selected currency must be a supported currency for the country that the bank account is located in. 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 will 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. If you select weekly or monthly, you'll be prompted to select which day. The very first transfer to your account may take up to 7 days to post.|
|Automatically add processing fee to amount||
This option should only be used 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" which will allow 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 allow 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 payment deposit accounts, you'll need to connect a particular payment_account prompt value (or the default for all payments), to one of the deposit accounts. You'll do this in the Application Editor.
First, select the application (round/period) to configure payments for. 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.
If you want to configure person-scoped payments (for example, an Event Fee payment for a person-scoped event), then 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).
Once you are editing a particular configuration, you'll see a list of application pages (if relevant) 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. To configure a default (or fallback) where all payments to go to the same deposit account, click the "payment" listing.
To configure 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 text that will be sent to a payer's bank (as evidence) whenever a payment of this type is disputed.
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 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 may wish to either:
- Set up the Deposit Accounts as above, refresh your test environment, and complete step three in your test environment, or else
- Create a separate test payment account prompt value (e.g. "Application Fee Test"), link that prompt value to Slate Payments while leaving the other provider live, and then switch later when you're ready to go live with Slate Payments.
If you have any concerns about testing while 'live' payments are ongoing, please open a Service Desk request in the "Payment Integration" category. You will also want to put in a Service Desk request to help with deactivating your previous payment integration, which may involve renaming files or deleting configuration sections from existing files.