⭐ Best Practice

Slate Payments offers cost benefits and additional features over external payment integrations. You should consider using Slate Payments or migrating to Slate Payments if you can.

Setting up an external integration

This section of the Knowledge Base offers articles specific to several of the most common external payment providers. Some institutions prefer to use payment vendors with whom they have an existing relationship or a contract. This article refers to setting up a customized implementation of an existing standard payment integration with Slate. An integration approach may not exist at all for a particular provider.

The specifics of how your instance of Slate integrates with your external payment provider depends on the specific providers used. In some cases, you can set up the integration yourself in the Application Editor.

📖 Further reading: Application Editor

For payment integrations not available for setup via the Application Editor, or if you use more than one payment provider, we are happy to make all adjustments to custom payment files through a support ticket.

Submit a ticket through the Support Desk with the required information (listed in the provider-specific documentation articles in this category) under the Payment Integration category, and our payments team will work on setting up the integration for you by adding and modifying files in your database’s Files tool (assuming that all relevant information has been provided to us via the ticket).

Our standard approach involves performing all payment integration set-up and testing in your production instance of Slate.

Initially, if your payment processor offers a test site/environment, we can connect your production Slate database to the test payment site of the payment processor. After successful testing, we'll change that integration to point to the processor’s production payment site. This approach reduces the need for retesting after the switch to production mode. We recommend performing at least one real-money test after switching to production, because some payment processors do not always replicate the environments precisely between their test and production.

General process flow

A payment page is rendered by Slate. When a user clicks the link to submit a payment on this standard Slate payment page, the steps that follow depend on the specific payment provider. External payment providers/processors handle the actual transactions, and in most all cases, host the payment pages where payment data is entered. The basic functionality is the same in most cases.

Handing off

When the applicant clicks the payment link, we pass data to the external payment provider to initiate and make the transaction possible, including at least the payment amount and certain identifying information for the applicant. The specifics vary. In some cases we assemble a page with a hidden form that is then submitted to the payment provider’s website/API, the user is redirected and the payment process is completed on that site. In a few other cases we collect the transaction details, such as credit card information, within a Slate page, and we submit that data to the payment provider behind the scenes. For some providers, a combination of these processes takes place.

After the payment completes

When the payment process is completed, either on the provider’s website or within Slate, two things typically occur:

1. The applicant is redirected back into Slate, either to a payment confirmation page, or more typically, to their own applicant status page.

2. A notification is sent to Slate from the external payment provider, letting us know that the payment succeeded. We pass certain transaction details (the application GUID, a transaction GUID, and the payment account) to the payment provider, and they pass these details back to Slate as part of the post-payment notification. That way, even if the notification comes in at a later time, we are able to associate the notification with the proper record and payment account in Slate. When we receive the payment notification (sometimes a "silent postback"), we create a Payment Received activity/interaction on the applicant’s record with the correct amount and payment account.

Refunds

Refunds for payments made through an external processor (and facilitated via Slate) must be initiated and processed in the external processor's system. These transactions are not transmitted back to Slate, and therefore will not be reflected in the payment history. You may wish to manually add payment refunded activities or interactions to the relevant records.

The external processor is your system of record for your payment/refund transactions. Only the actual initial charge for the payment collected in Slate is transmitted. Do not rely on the payment history for reconciliation purposes, using the data from the external processor is recommended instead.

Integrating with multiple (external) payment processors

You can certainly use more than one processor for different types of payments. A particular payment integration can be specified for a particular period or round, for a particular payment account, or a combination of both.

The most common scenario is to send different payment accounts to different vendors (for example, an Application Fee goes to Slate Payments and an Enrollment Deposit goes to your campus vendor).

For more complex requirements, it may be helpful to add additional payment accounts, use those in different payment rules, and route them to different vendors.

Person-scoped payments

The majority of payments in most Admissions databases are application-scoped (application fees, deposits, events), but there will also be person-scoped payments (event payments, gifts). Depending on the external processor, the setup may be slightly different.

For processors where the configuration takes place in the application configuration, it must be replicated at the person level. In practice that means to following:

1. If the processor can be set up in the Application Editor without our assistance, then for person-scoped payments you should repeat that setup using the Person-scoped Payment Configuration link from your Database page.

2. If we are involved in setting up your payment integration, you should let us know if person-scoped payments will be accepted, and you should contact us if you want to add person-scoped payments at a later point in time. In some cases no change will be necessary, but we can check and verify that for you.

Limitations to external payment processors

• We may not have an available integration at all for your preferred payment processor.

• No in-form or event payments: External Payment Processors cannot be used within the Slate payment widget to collect payments on a form/event.

• No tap-to-pay: The Payment Terminal / tap-to-pay feature is only available with Slate Payments.

  • If using an external processor, you will not be able to accept in-person payments from contactless credit or debit cards, Apple Pay, Apple Watch, and smartphones with other digital wallets within the Slate mobile app.

• No dataset-scoped payments: These types of payments are not supported when using an external payment processor. Payments for dataset records can only be facilitated via Slate Payments, using the payment widget.

• Refunds: Refunds for payments made through an external processor facilitated via Slate must be initiated and processed using the external processor's system.

Fees for configuring an external payment provider integration

There are no additional fees associated with Technolutions setting up an existing available external payment processor integration for your institution.