Many institutions choose to use our built-in payment provider (Slate Payments), but other institutions prefer to use payment vendors with whom they have an existing relationship or a contract (and for which a payment integration with Slate already exists).

If you're interested in our built-in payment processor (instead of or in addition to integrating with an outside vendor), please review our Slate Payments documentation.

Setting up an 'External Integration'

The specifics of how your instance of Slate will be integrated with your payment provider will depend on the provider or mix of providers used. In some cases, you can set up the integration yourself (through the Application Editor interface).

For any existing and available external provider payment integration not available as a "self-service'" setup through the Application Editor (or whenever you are using a mix of payment providers), we will make all adjustments to custom payment files through a support ticket! Submit a ticket through the Support Desk with the specific required information (listed in the other provider-specific documentation articles in this category) under the Payment Integration category, and our payments team will set up the integration for you (by adding and modifying files in your File Editor).

Our standard approach is to do all payment integration set-up and testing in your production instance of Slate. Initially, if your payment processor offers a test site, 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 production payment site. This approach reduces the need for retesting after the switch to production. We recommend performing at least one real-money test after switching to production, because some payment processors do not always replicate the environment precisely between test and production.

General Payment Flow

When a user clicks a link to submit a payment on the standard Slate payment page, the steps that follow depend on the payment provider. External payment providers/processors handle the actual transactions, and in most 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 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 submitted to the payment provider’s website, and the payment process is completed on that site. In 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 complete, either on the provider’s website or within Slate, two things typically occur:

1. The applicant is redirected 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 ID, a transaction ID, and the payment account) to the payment provider, and they pass these details back to Slate as part of the 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. When we receive the payment notification (sometimes called a "silent postback"), we create a Payment Received activity/interaction on the applicant’s record with the correct amount and payment account.

Fees for configuring an external payment provider integration

We do not charge any additional fees for setting up an existing external payment processor integration for you.

Integrating with Multiple 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 one vendor and an Enrollment Deposit goes to another).

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 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.

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. 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.

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, as they are the system of record for your payment/refund transactions.