Payment Cardholder Data Flows
LearningBuilder only uses PCI-Compliant payment gateways to process financial transactions. This page documents the technical details behind each supported CheckoutMode.
Overview
Regardless of the configured payment gateway and CheckoutMode, LearningBuilder never receives, stores, or processes payment card data. All credit card information is submitted securely to the payment gateway, never touching the LearningBuilder network or application.
The details of how each CheckoutMode implements this requirement are below.
Secure Post
In the SecurePost mode, a form containing credit card data is submitted to a web application, which then forwards that credit card information to the gateway in a server-side API call.
LearningBuilder policies prevent the implementation of any payment gateways using Secure Post.
Hosted Pages
In the HostedPages model, the user’s browser is fully redirected to the payment gateway’s website to perform the checkout process.
User enters checkout in LearningBuilder
(optional) User enters non-payment-card data such as their shipping address
User’s browser is redirected to the payment gateway’s website over HTTPS, completely severing their connection to LearningBuilder.
User provides credit card information to the payment gateway, which performs the transaction.
Upon success, the user is redirected back to LearningBuilder and sees the payment success message.
The transaction ID is provided to LearningBuilder in one of two ways:
The gateway makes an API call to LearningBuilder to post the transaction details before redirecting the user, -OR-
The gateway sends the transaction details as querystring parameters in the redirect URL
Hosted Pages + iFrame
The HostedPagesIFrame model is similar to HostedPages, except that instead of fully redirecting the user’s browser to the payment gateway’s website, the gateway’s checkout form is embedded within LearningBuilder using an <iframe>.
User enters checkout in LearningBuilder
(optional) User enters non-payment-card data such as their shipping address
LearningBuilder displays a checkout page, which consists of the LearningBuilder site “chrome” plus an
<iframe>that displays a form hosted by the payment gateway. The checkout form is loaded using HTTPS within the<iframe>.User submits credit card information within the
<iframe>, posting it directly to the payment gateway.Upon success, a payment success message is displayed within the
<iframe>and the transaction ID is posted to LearningBuilder as an API call. The user can then continue with their process within LearningBuilder.
Even though the user’s browser seems to remain on the LearningBuilder website, LearningBuilder never receives or processes any credit card information; it is submitted directly to the payment gateway.
Two-step Client Side
In the TwoStep model, LearningBuilder hosts the form that collects credit card information. This form, however, makes an HTTPS post to the payment gateway, NOT to LearningBuilder.
User enters checkout in LearningBuilder
LearningBuilder displays a form that collects the billing address and credit card information. The
<form>'sactionattribute points to the payment gateway over HTTPS.When the user clicks the submit button, their browser initiates the HTTPS POST and navigates to the payment gateway endpoint.
The payment gateway performs the transaction and, upon success, redirects the user’s browser back to LearningBuilder.
Even though the credit card form is displayed by LearningBuilder, the data it collects is submitted elsewhere.
The transaction ID is provided to LearningBuilder in one of two ways:
The gateway makes an API call to LearningBuilder to post the transaction details before redirecting the user, -OR-
The gateway sends the transaction details as querystring parameters in the redirect URL
Three-step Handshake
In the ThreeStep mode, the credit card form is hosted by LearningBuilder. This form makes a background HTTPS post to payment gateway and “trades” the credit card details (which LearningBuilder does NOT store or process) for a “token” (which LearningBuilder DOES store and process). When the user confirms their intent to make the payment, LearningBuilder sends that token back to the gateway to initiate the transaction.
User enters checkout in LearningBuilder
LearningBuilder displays a form that collects the billing address and credit card information. The
<form>'sactionattribute points to the payment gateway over HTTPS.When the user clicks the submit button, client-side JavaScript code performs an asynchronous HTTPS POST to the payment gateway, submitting the credit card information.
The payment gateway securely stores those details, returning a “token” back to LearningBuilder. LearningBuilder attaches this token to the user’s checkout process.
LearningBuilder displays an order confirmation screen to the user, summarizing the transaction they are about to perform.
User clicks a “submit order” button. LearningBuilder makes a background API call to the payment gateway, specifying the order details (amount, etc) and providing the token in lieu of any payment card data.
The payment gateway uses the token to look up the stored credentials and then performs the transaction.
The payment gateway returns the transaction details, including card authorization, in the API call response.
The “token” is a one-time-use identifier for a set of payment card credentials. It is not an encrypted or encoded version of the credentials and therefore cannot be reverse engineered into the specific credit card number. The token cannot be reused to perform additional transactions.
Security of transaction IDs and transaction history
LearningBuilder records the transaction ID as reported by the payment gateway, but does not store any sensitive information about the transaction.
Additionally, there are no direct links between LearningBuilder and the various payment gateway administrative dashboards; staff have no ability to obtain additional information about a given transaction ID unless they also have sufficient login credentials for the payment gateway itself.