| 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 |
...
For more information on establishing a merchant gateway, see below.
Supported Gateways
...
| 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.
|
|
|
|
|
| |
Authorize.Net |
LearningBuilder supports the PCI-compliant |
“Three-Step |
Handshake” checkout mode.
|
Refund processing is not supported in LearningBuilder.
| Warning |
|---|
As of February 2021, using this gateway in “Secure Post” mode is disallowed by policy because it is not PCI-compliant. The “Secure Post” mode will be removed 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 Three-Step Handshake Checkout Mode.
| Note |
|---|
Versions of LearningBuilder prior to 11.0.4 are at risk of allowing duplicate payments or improper error handling. Please be sure you are using an up-to-date version of the software. |
USAePay
| |||
Moolah | LearningBuilder Supports the PCI-compliant “Three-Step Handshake” checkout mode.
| ||
USAePay | LearningBuilder supports the PCI-compliant "Two-Step Client-Side" checkout mode |
.
|
|
| |||
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.
|
|
|
|
|
|
Gateway / feature support matrix
| Info |
|---|
Legend:
|
- Gateway does not support the featureVendor / Gateway | App Config value for | Checkout Modes | Supported Features | |||||||
|---|---|---|---|---|---|---|---|---|---|---|
Full | Partial | GL | Discount | Responsible Party ‘Pending’ Payments (aka Bulk Employer Payments) | Organization ‘Bulk’ Payments | (Legacy) Learning Plan Task Payments | ||||
Payflow Payments Pro | PayPal |
|
|
|
|
|
|
|
|
|
Payflow Pro | PayflowPro |
|
|
|
|
(Added with 10.0 Release) |
( |
|
|
|
Moolah | Moolah |
|
|
|
|
|
|
|
|
|
Authorize.Net | AuthNet |
| ||||||||
(v. 11.0.15+) |
(v. 11.0.15+) |
|
( |
|
|
|
| |||
USAePay | USAePay |
|
|
|
|
|
|
|
|
|
Alabama Interactive | AlabamaInteractive |
|
|
|
|
|
|
|
|
|
Checkout Modes
Many payment gateways support multiple “checkout modes”, each offering a different user experience or feature set.
...
For more information about PCI Compliance for each gateway, see the Compliance docs
Method | App Config value for
| Description / PCI Compliance | ||||
|---|---|---|---|---|---|---|
Secure Post |
| Payment forms are hosted by LearningBuilder. Payment card data is transmitted to LearningBuilder, which then submits the payment transaction to the gateway.
| ||||
Hosted Pages |
| 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.
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 |
| 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.
| ||||
2 Step Client-Side |
| 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.
See the USAePay documentation for more information | ||||
3-Step Handshake |
| 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.
|
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
EnableCreditCardValidationApp 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.
...
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)
...
.
...
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 settingsIf 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. |
In LearningBuilder versions 11.0.1, 11.0.2, and 11.1.0, a user is able to create duplicate transactions in AuthNet, USAePay, and Moolah. This issue has been resolved in 11.0.3. See
Jira Legacy server System JIRA serverId 80a5de98-58ff-3b59-a4bd-e013083b8a1d key LB-2716 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 JIRAJira 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 https://heuristicsolutions.atlassian.net/wiki/spaces/DOCS/pages/3099492370/Moolah+-+Known+Issues+Observations#Duplicate-Payment-Race-Condition and https://heuristicsolutions.atlassian.net3596681219 and /wiki/spaces/DOCS/pages/3099656228/Authorize.Net+-+Known+Issues+Observations#Duplicate-Payment-Race-Condition for more information. This window also exists in the PayflowPro/SecurePost configuration. Refer to https://heuristicsolutions.atlassian.net/wiki/spaces/DOCS/pages/3101524085/Payflow+Pro+-+Known+Issues+Observations#Duplicate-Payment-Race-Condition3596353605 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.
...