Common Checkout Pages

A disconnected payment page. We host it so you don’t have to.

The Common Checkout Page (CCP) application provides an easy to use checkout module that alleviates the major costs incurred in meeting the obligations of securing your customer’s data.

With CCP, Tyler Technologies provides a fully hosted set of checkout pages for credit card, eCheck, and more, that are PCI compliant. CCP is fully configurable to allow for agency specific branding, multilingual capabilities, customizable fee structures, and customizable receipt formatting.

redirect icon

User Facing with Redirect

Integrate CCP into your application while redirecting to our payment page.

See Redirect Sample
iFrame icon

User Facing in iFrame

Integrate payments into your application while keeping users on your screen.

See iFrame Sample

Technical Overview

Here your application will be referred to as the Partner Application, or PA. Common Checkout is referred to as CCP. The general workflow is:

  1. PA sends CCP a REST request describing the payment required
    • This includes a unique identifier you generate for reconciliation (localrefid). This could be a session id, filing number, or, if it’s say something that should only be submitted once per year, a user id + year to ensure it can not have duplicates.
    • It will also include a three-part key that will identify the service you’re billing for to our system (see one for test near the end of this email).
    • If you already have some information such as the phone number or billing address you can have it pre-populated with this call.
  2. CCP responds with a token that is valid for 30 minutes.
    • You can use the getOrder call to check status for this token to ensure that payment hasn’t already been made before sending the user over.
  3. PA redirects user to CCP with the token
  4. User submits their payment info for billing
  5. CCP redirects the user back to PA upon completion via an href you provide during the prepare call and depending on the result.
    • SuccessUrl is used following a successful payment
    • FailureUrl is for a failure such as insufficient funds, do not honor, etc
    • DuplicateUrl for a previous payment
    • CancelUrl if the user clicks the cancel button
  6. If configured, CCP will call a webhook in your application and deliver a JSON object describing the payment
  7. The response will include the token and an error code and message if there was a problem. It will include the token, the CCP/TPE order id, and other details upon success. Your application can use these to provide some confirmation of receipt, follow-up, etc.

The response will include the token and an error code and message if there was a problem. It will include the token, the CCP/TPE order id, and other details upon success. Your application can use these to provide some confirmation of receipt, follow-up, etc.

It is possible that the user successfully paid but did not make it back to the PA to finish processing. Because of this the PA must include a background process to call getOrder on any incomplete tokens. Unpaid tokens older than 30 minutes can be removed from the system. Tokens that were successfully paid should be processed as if the user had made it back to the PA.

CCP has the option of sending the user an email receipt and displaying the user a receipt on-screen before returning them to your application. However there are some things to consider and it’s general best for your application to handle these whenever possible. The receipts it generates will only include the limited information you provide CCP and not the larger context or branding your application can provide. Our email receipts also cannot be re-sent later should someone delete theirs or needs it sent to someone else later.

We can customize the look of CCP with your branding to ease the user’s transition from your application to CCP and back.

Client Application and Common Checkout workflow graphic