⭐ Best Practice

Slate Payments offers cost benefits, easy maintenance, and additional functionality beyond what is available when using external payment processor integrations. You should consider using Slate Payments first, or migrating to Slate Payments whenever you can!

Configuring an external payment integration

Slate works with many payment providers who handle payment transactions. In most cases, these external providers host the payment pages where payment data is entered. The basic functionality is frequently very similar and the initial configuration requirements for each provider are outlined in individual articles in this section. You should be familiar with the basic concepts related to payments in Slate as outlined in the 'Getting Started' section. Plan carefully and make allowance for a 4-6 week implementation project. Please review the article pertaining to your preferred external payment provider your before you open a support ticket!

Some institutions prefer to (or must) continue using payment vendors with whom they have an existing relationship or campus-wide contract. This article refers to configuring a customized implementation of an existing standard external payment integration template within Slate. An integration approach may not exist at all for a particular provider, in which case you should consider setting up Slate Payments. If Slate Payments (Stripe Connect) is not available in your jurisdiction, please reach out to us via a Support ticket.

The specifics of how your particular Slate database integrates with your preferred external payment provider depends on the specific provider. In some cases, you can configure the integration yourself in the Application Editor (we outline this in the provider-specific articles).

📖 Further reading: Application Editor

For payment integrations not available for self-service setup via the Application Editor, or if you use more than one payment provider, we will make all adjustments to custom payment configuration files through a Support ticket.

Open a Support ticket with the required information (listed in the respective provider-specific documentation articles in this category) under the Payment Integration category, and our payments team will review the context and 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 environment. You can refresh your Test environment, if you have to, which will then make the payment integration available there (in Test) without much additional work, but we generally do all testing in the production environment: (a) to avoid our work getting erased by other Test refreshes, (b) to ensure that the payment processor’s postback notifications actually reach the intended database. You need this to work in production, against production, with the remote system posting back to production!

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 or API endpoint. 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 initiation page is rendered by Slate. When an end user clicks the available button or link to submit a payment on this standard Slate payment page, the steps that follow depend on the specific provider. External payment providers/processors handle the actual payment transactions, and in most all cases, host the payment pages where the actual payment data is entered. The basic functionality is the same in most cases.

Handing off

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

After the payment completes

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

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

2. A notification is sent to a specific Slate endpoint 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 prompt value) to the payment provider during the initial handoff, and they pass these details back to Slate as part of their 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 called a "silent postback"), we create a Payment Received activity on the person’s record (or an application record) with the correct amount and payment account.

Note: It is possible that notifications sent to Slate are not properly processed (timeouts, connectivity issues, missing postback data), or do not arrive at our servers at all (due to other network issues, or problems at the processor’s system). None of the external payment integrations (to our knowledge) are set up on the processor’s end to automatically re-try their notifications to us when they don't receive the 'ok' signal from our server. There is nothing we can do to change the behavior of the external system in this regard. Remember that, unless you are using 'Slate Payments', the external processor is your payments system of record!

Refunds

Refunds for payments made through an external processor (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 will have to manually add payment refunded activities to the relevant records, if you want to record the accurate state of affairs in Slate.

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 back to us. Do not rely on the payment history for full reconciliation purposes; use the data from the external processor is recommended to verify.

Integrating with multiple (external) payment processors

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

The most common scenario is to send different payment accounts to different vendors (for example, Application Fees or Event registrations go to Slate Payments, while an Enrollment Deposit might have to go to your campus vendor and the SIS).

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. We can review and discuss options as part of the Support ticket.

Person-scoped payments

The majority of payments in most Admissions/Enrollment-focused databases are application-scoped (application fees, deposits, orientation 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 Editor configuration, it must be replicated at the person level. In practice that means:

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

2. If we are involved in setting up your initial integration, you should let us know in the Support ticket, 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.

Limitations when using external payment processors

• We may not have an existing available integration at all for your payment processor !

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

• No tap-to-pay or in-person payments: 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 payments for dataset-scoped records: 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.

• No easy Refunds in Slate: Refunds for payments made through an external processor 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 / configuring an existing already available external payment processor integration template for your institution.