Info

LearningBuilder can collect payments from end-users in many different ways. Adding integrations for gateways not listed here is generally possible with minor innovation.

See also: Payment and E-Commerce Features

Table of Contents

Overview

LearningBuilder itself does not handle credit card transactions. Instead, it integrates with a variety of payment processing systems to handle those transactions.

...

For more information on establishing a merchant gateway, see below.

Supported Gateways

...

Payflow Payments Pro
(aka PayPal)

...

This service uses PayPal as the payment gateway and payment processor. PayPal performs all transaction processing prior to depositing into the client's merchant account. Customers using Payflow Payments Pro sign up for PayPal Pro service, which is around $30/month (as of July 2012). PayPal Payments Pro uses the concept of a "sandbox" for performing test transactions and a separate, live site. Payment processing is available through Secure Post mode but refund processing through LearningBuilder is not supported.

Warning
As of February 2021, this gateway is disallowed by policy because it does not support a PCI-compliant payment option. This gateway will be fully removed from the software in an upcoming release.

...

Warning

By policy, LearningBuilder integrations are prohibited from using non-PCI-compliant checkout modes, such as “Secure Post”.

Support for non-PCI-compliant methods remains in the software during a migration period but will be removed in a future release, and may not be used for new integrations.

/wiki/spaces/DOCS/pages/3040182285

PayPal offers multiple payment products, but the only one that is both PCI compliant and fully supported by LearningBuilder is Payflow Pro.

For more information on the other PayPal offerings, see PayPal Payment Gateways

This service uses PayPal as the Payment Gateway but uses a third party payment processor. This interface is the result of PayPal's purchase of Verisign, which first developed the Payflow Pro product. PayPal now uses it for advanced interfaces that use other payment processors. Payments and refunds are both functional, and are supported in both the Secure Post and Hosted Pages iFrame Checkout configurations.

Info
Required Configuration:

The client’s gateway account must be configured to use

LearningBuilder requires that the client’s PayPal account be configured for Hosted Pages with the “Silent Post” feature

to prevent orphaned payment records in LearningBuilder. In the Payflow Pro Manager site, configure the account like so:

Use Silent Post: enabled
Void Transactions That Fail Silent Post: enabled
Silent Post URL: blank

See PayflowPro Silent Post for more details.

WarningAs of February 2021, using this gateway in “Secure Post” mode is disallowed by policy because it does not support a PCI-compliant payment option. Use “Hosted Pages” mode instead. The “Secure Post” mode will be removed from the software in an upcoming release

Moolah

Moolah is an alternative gateway which is focused on Non-Profit organizations. The support of this gateway was introduced in LearningBuilder 8.10 and is only functional in the 3-Step Handshake Checkout Mode.

USAePay

USAePay provides a number of payment solutions. Currently, LearningBuilder supports the "2

enabled.

See /wiki/spaces/DOCS/pages/3596681278 for details.

Note
LearningBuilder versions earlier than 11.0.1 may not properly detect duplicate payments in all cases.

Authorize.Net

Authorize.Net is an alternative gateway to PayPal. If the organization has already established a relationship with Authorize.Net and wishes to use this gateway, LearningBuilder can be configured to support it. Payment processing is available but refund processing through LearningBuilder is not supported. This Payment Gateway is functional in Secure Post and 3-Step Handshake Checkout Modes.

Warning
As of February 2021, using this gateway in “Secure Post” mode is disallowed by policy because it does not support a PCI-compliant payment option. Use “3 Step Handshake” mode instead. The “Secure Post” mode will be removed from the software in an upcoming release.

LearningBuilder supports the PCI-compliant “Three-Step Handshake” checkout mode.

Note
LearningBuilder versions earlier than 11.0.3 may not properly detect duplicate payments in all cases.

Moolah

LearningBuilder Supports the PCI-compliant “Three-Step Handshake” checkout mode.

Note
LearningBuilder versions earlier than 11.0.4 may not properly detect duplicate payments in all cases.

USAePay

LearningBuilder supports the PCI-compliant "Two-Step Client-Side"

mode only for this gateway

checkout mode.

Note
LearningBuilder versions earlier than 11.0.4 may not properly detect duplicate payments in all cases.

Alabama Interactive

Alabama Interactive is a payment gateway used by licensing agencies in Alabama. It offers both a “Hosted Pages” and “Hosted Pages iFrame” option, but LearningBuilder only supports the “Hosted Pages” mode at this time.

Info
Required Configuration: The client’s gateway account must be configured to use the “Postback Service” feature to prevent unrecorded payments in LearningBuilder. For more information, see

the configuration page

Client-Side Configuration of Alabama Interactive.

Note

Unlike Payflow Pro, Alabama Interactive does not have a way to guarantee against unrecorded payments. If an error occurs while notifying LearningBuilder of a successful transaction, they will retry a set number of times and then send an email.

We recommend using one of the other gateways instead that offer more robust protections against unrecorded payments.

Note
LearningBuilder versions earlier than 11.0.1 may not properly detect duplicate payments in

LearningBuilder

all cases.

Gateway / feature support matrix

...

Info
Payment gateways support different features. If a feature is not supported, it may be because the gateway does not support it , or we have not added support in LearningBuilder for that feature in the gateway .

Vendor

Legend:

- Gateway does not support the feature

- Gateway supports the feature, but the LearningBuilder integration does not

Vendor / Gateway

App Config value for PaymentGateway

Checkout Modes
(see below for details)

Supported Features
(follow links for details)

Secure
Post

Hosted
Pages

Hosted
Pages
+ iFrame

3 Step
Hand-shake

2 Step
Client-
Side

Full Refunds	Partial Refunds	GL Codes	Discount Vouchers	Tenant-Specific Settings	Responsible Party ‘Pending’ Payments (aka Bulk Employer Payments)	Organization ‘Bulk’ Payments	(Legacy) Learning Plan Task Payments No new LB instances should use this feature, regardless of gateway support
Payflow Payments Pro (deprecated)	PayPal

Secure Post
Payflow Pro	PayflowPro

Secure Post

Hosted Pages IFrame

(Added with 10.0 Release)

( Secure Post Only)

Moolah

Moolah

3 Step Handshake

Authorize.Net

AuthNet

Secure Post

3 Step Handshake

(v. 11.0.15+)

( 3-Step Handshake)

USAePay

USAePay

	2 Step Client-Side
Alabama Interactive	AlabamaInteractive

Hosted Pages

Checkout Modes

Many payment gateways support multiple “checkout modes”, each offering a different user experience or feature set.

LearningBuilder integrations only support the PCI compliant modes.

The PaymentGateway and CheckoutMode App Config setting controls the user’s experience during checkoutsettings must be set to a supported combination.

For more information about PCI Compliance for each gateway, see the Compliance docs

Method

App Config value for

CheckoutMode

Description / PCI Compliance

Secure Post

SecurePost

Payment forms are hosted by LearningBuilder. Payment card data is transmitted to LearningBuilder, which then submits the payment transaction to the gateway.

Warning
This mode is not PCI compliant and is disallowed by policy in 10.6.0 and later. It will be removed from the software in a future version.

Hosted Pages

HostedPages

When the user begins checkout, their browser is redirected to the payment gateway’s website. The credit card form is hosted by the gateway and the entire transaction occurs externally to LearningBuilder. The user is redirected back to LearningBuilder after the transaction is complete.

Tip
This approach is secure because LearningBuilder is entirely removed from the checkout process and has no opportunity to collect or transmit payment card data.

The main drawback to this approach is that the payment gateway’s checkout form often does not look exactly like LearningBuilder, resulting in a disjointed user experience.

On the other hand, innovations made by the gateway to their checkout experience (such as adding support for new payment types) can be immediately available to end users without requiring changes to LearningBuilder.

Hosted Pages
+ iFrame

HostedPagesIFrame

This is similar to Hosted Pages, except that instead of redirecting the user to a 3rd-party checkout process, the 3rd-party checkout form is displayed in an iframe within LearningBuilder.

This often results in a more seamless user experience because the user never leaves the context of the LearningBuilder site.

Tip
This approach is secure because the credit card form is hosted by and submitted to the payment gateway. LearningBuilder is not involved in the collection or processing of credit card data in any way.

2 Step Client-Side

TwoStep

In this mode, the checkout process is implemented within LearningBuilder except for the credit card processing. When the user submits the form containing credit card data, the form submits directly to the payment gateway which handles the transaction and then redirects the user back into LearningBuilder.

Info
This mode provides a mostly seamless checkout experience, except that LearningBuilder cannot display a “checkout confirmation” page after the credit card data is entered but before processing the transaction. The card data is submitted directly to the gateway, so the confirmation page, if any, must be handled by the gateway as well.

Tip
This approach is secure because the credit card form, though hosted by LearningBuilder, is submitted directly to the gateway for processing. Credit card data is not submitted to or transferred by LearningBuilder in any way.

See the USAePay documentation for more information

3-Step Handshake

ThreeStep

After the user enters their credit card information, LearningBuilder submits that data directly to the payment gateway as a background post. The user’s browser does not navigate away from LearningBuilder.

The gateway securely stores the credit card data, without processing a transaction, and returns a token that can be used to reference those saved credentials at a later time.

The user then finishes the checkout process in LearningBuilder, which includes a “checkout confirmation” page. Once the user confirms their intent, LearningBuilder makes a second background post to the gateway. This post includes the transaction details (amount, etc) plus the token that was received earlier. The payment gateway then uses the stored card data to complete a transaction.

Info
This approach provides a seamless user experience without sacrificing security. It is the recommended approach for many customers.

Tip

This approach is secure because no credit card data is submitted to or processed by LearningBuilder in any way. The credit card data is submitted directly to the gateway, which then gives LearningBuilder a secure, one-time-use token for referring to those credentials at a later time. This token cannot be used to “reverse engineer” or compromise the card details.

For more information on this methodology, see this link.

PCI Compliance

As of 10.6, LearningBuilder does not support any payment gateways or checkout modes in which payment card data is transmitted to or processed by LearningBuilder. In order to maintain PCI compliance, LearningBuilder cannot have anything to do with credit card details.

...

The EnableCreditCardValidation App Config setting is deprecated and has no impact on a PCI-compliant payment gateway. The credit card data is transmitted directly to the payment gateway and is not examined by LearningBuilder in any way.
When using the BACK button to navigate backward from the Review page to the Checkout page, the credit card information is not persisted and must be re-entered.

Obtaining an Internet Merchant Account

To accept credit cards over the Internet, you need a special account called an Internet Merchant Account. If PayPal is your merchant bank, you do not need the Internet Merchant Account. Your account provider or merchant (acquiring) bank works with a PayPal-supported credit card processor. Examples are First Data, TSYS Acquiring Solutions (formerly Vital Processing Services), and Paymentech. To accept live credit cards, provide details about your account to PayPal during the "Go Live" part of enrollment.

An Internet Merchant Account is a different type of merchant account. It has additional risks associated with card-not-present (e-commerce) transactions. It is different from a merchant account used for face-to-face/card-present (in-person) retail transactions. Obtain an Internet Merchant Account even if you already accept credit cards at your location. To apply for an Internet Merchant Account, contact your merchant (acquiring) bank.

...

On a LearningBuilder™ support site, set up the Payment Gateway in a test mode.
- Attempt an invalid payment (using an expiration date in the past)
- Attempt a valid `payment (using the special credit card number)
On the LearningBuilder™ support site, set up the Payment Gateway in a live mode.
- Attempt an invalid payment (using an expiration date in the past)
- Attempt a valid payment (using a real credit card and a small payment amount; e.g. $0.02)
On the LearningBuilder™ live site, set up the Payment Gateway to match the support site.
- Attempt an invalid payment (using an expiration date in the past)
On the LearningBuilder™ support site, set the Payment Gateway back into a test mode.

The Fake gateways support three simulated responses:

FirstName = "MissingId": This will result in an Approval but no Transaction ID
FirstName = "Decline": This will result in a Declined status.
FirstName = Anything else: This will result in an approval.

Testing a payment gateway integration

Info

Testing payment gateway settings

If you append "Fake" to the end of the PaymentGateway app config value, the system will simulate connecting to the gateway without actually doing so. This is useful when testing in a non-production environment.

...

Known Issues / Observations

Info
This document outlines known issues, outstanding items, or extra notes as they relate to most or ALL payment gateways. For gateway-specific documentation, refer to the gateway-specific documentation.

If a Payment Attribute is added to a role grant workflow with a success action that grants the role, successfully completing the payment does not redirect the Practitioner to an auto-started Learning Plan Instance (LPI). This is counter to the expected case, where normally granting oneself a role will redirect the Practitioner to the LPI associated with that role if the Learning Plan Definition is set to “automatically begin when eligible.” See
Jira Legacy
server System Jira
serverId 80a5de98-58ff-3b59-a4bd-e013083b8a1d
key LB-2653
There is a small window of time within the ThreeStep Checkout Mode where a duplicate payment is possible. Refer to /wiki/spaces/DOCS/pages/3596681219 and /wiki/spaces/DOCS/pages/3099656228 for more information. This window also exists in the PayflowPro/SecurePost configuration. Refer to /wiki/spaces/DOCS/pages/3596353605 for more information.
If a site app pool is recycled before payment is fully confirmed, the payment will redirect to a post-processing error page and a web error email (“The same key was already used for another template!”) will send. This occurs within the ThreeStep Checkout Mode and with the PayflowPro/SecurePost configuration.

Payment Features in LearningBuilder

Child pages (Children Display)

Versions Compared

Old Version 39

New Version Current

Key

Overview