Using an External Processor to Collect Payments through Slate

When a user clicks a link to submit a payment, the steps that follow depend on the payment provider. Payment providers 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; later we will cover specific differences between providers. Many institutions choose to use our built-in payment provider (Slate Payments), but other institutions prefer to use payment vendors with whom they already have a relationship or a contract.

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

Handing Off

When the applicant clicks the payment link, we pass data to the payment provider to make the transaction possible, including at least the payment amount and the 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 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 or interaction on the applicant’s record with the correct amount and payment account.

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 service request! Submit a request through the Service Desk with the specific required information (listed in 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.

Fees for existing external payment provider integration

We do not charge any additional fees for setting up a payment 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 are application-scoped (application fees, deposits), 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.

Refunds

Refunds for payments made through an external processor via Slate must be processed using the external processor' system. These transactions are not transmitted back to Slate, and therefore will not be reflected in the payment history. Only the actual charge for the payment collected in Slate is transmitted. If you are using 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.

Was this article helpful?
7 out of 7 found this helpful