On this page
- Overview
- How the checkout widget works
- Typical checkout journey
- Generating the checkout widget
- Example widget container
- Configuration options
- What checkout can include
- Payment considerations
- Where checkout fits in the storefront journey
- Testing the checkout widget
- Common issues
- Related articles
Overview
The Checkout Widget is the WebLink component that allows a learner to complete a booking after selecting a course or event from your storefront. It acts as the bridge between browsing training and submitting the registration or order.
In most WebLink implementations, the learner first finds training through a catalog or event listing widget, then moves into checkout to complete the booking journey.
If you have not yet set up the broader WebLink environment, start with WebLink Overview and Installation. For the catalog stage of the journey, see WebLink - Catalog Widget.
How the checkout widget works
The Checkout Widget takes the learner from a selected training option into the booking flow. Depending on your configuration, the widget may collect learner details, confirm pricing, capture additional order information, and pass the booking into Administrate.
This means the checkout experience is not just a visual step. It is the point where storefront activity becomes an actual booking or order record.
If an event_id is not provided, the checkout flow can first present the event selection stage instead of going directly to booking.
The Checkout Widget can also be reached from other WebLink components, including the event listing flow, when the learner selects Register Now.
Because of that, checkout should always be tested end-to-end before launch.
Typical checkout journey
A common learner flow looks like this:
- The learner browses the training catalog.
- The learner selects a course or event.
- The learner enters the checkout flow.
- The learner confirms the booking details.
- The learner completes the transaction or registration.
- Administrate creates the resulting booking or order record.
The exact journey depends on whether you use open registration, payment collection, additional order fields, or other storefront rules.
Generating the checkout widget
The easiest way to generate the widget is by using the WebLink Builder.
- Open the WebLink Builder.
- Enter your portal address URL.
- Select the timezone you want to use.
- Choose Checkout Widget from the widget list.
- Adjust any available configuration options.
- Click Build to generate the code.
The builder generates:
- the shared WebLink setup script
- the widget container for checkout
Both parts must be present for the checkout experience to work correctly.
Example widget container
A basic checkout widget container may look similar to this:
<div class="administrate-widget" data-widget="checkout"></div>
In older WebLink implementations, checkout may also be configured using a container such as:
<div class="administrate-widget" id="widget" data-administrate-checkout="event_id=1"></div>
The exact code will depend on the configuration generated by the builder.
Configuration options
Older checkout implementations exposed a set of configuration options directly on the widget setup. Where applicable in your environment, these include:
| show_year | true|false — Include event year when showing dates. Default: false. |
| show_times | true|false — Include event times when showing dates. Default: false. |
| tax_label | Tax label text, for example VAT. Default: VAT. |
| basis | Show prices net or gross of tax. Default: net. |
| currency | Currency code used for display. An event will only display if there is a price in that currency. Example: GBP. Default: GBP. |
| currency_indicator | Choose whether to display the currency as a symbol or code. Default: symbol. |
| currency_list | Used when supporting multiple currencies and payment processors, for example {'USD':'Stripe', 'GBP':'PayPal'}. |
| show_currency_indicator | true|false — Show the currency indicator. Default: true. |
| step1_course_fields | Comma-separated list of fields to show in step 1. Options include: code, summary, schedule, location, inclusions, method, prerequisites, topics, benefits, duration. |
| step4_course_fields | Comma-separated list of fields to show in step 4. Options include: code, summary, schedule, location, inclusions, method, prerequisites, topics, benefits, duration. |
| terms | Text to display as Terms and Conditions. |
| payment_by_invoice | true|false — Allow payment by invoice (delayed payment). Default: true. |
| invoice_instructions | Instructions to display on the final step for invoice-based checkout. |
| invoice_send_email | true|false — Control whether to send the client an invoice email when the order is completed. Default: true. |
| payment_by_cc | true|false — Allow payment by credit card through the configured payment provider. |
| payment_processor | Payment provider to use. Older options included PayPal, SagePay, Stripe, and WPM. |
| paypal_mode | Set the PayPal mode. Older documentation referenced Live. |
| sagepay_mode | Set the SagePay mode. Older documentation referenced Test and Live. |
| cc_instructions | Instructions to display on the final step for card payments. |
| show_promo_codes | true|false — Display the option to enter a promo code. |
| cc_send_email | true|false — Control whether to send the client an invoice email upon order completion. Default: true. |
| use_sales_opportunities | true|false — Whether to route orders into the newer sales opportunities system. Default: false. |
| show_classroom_dates | true|false — For blended learning events, show classroom session dates rather than the full event duration including LMS access. |
| event_id | ID of the event to book directly. |
If you are using payment processing, also review your integration setup: Integration Settings.
Note: In older Stripe-based setups, the key used determined whether checkout operated in test or live mode.
Note: Older documentation also stated that PayPal had dropped support for sandbox checkout testing and that this option would be removed in a future version.
What checkout can include
Depending on your setup, the checkout experience can include:
- learner or purchaser details
- selected course or event information
- price confirmation
- currency handling
- payment options
- additional order fields
If your booking flow requires more data than a standard self-service registration, make sure those required fields are configured before publishing the storefront.
For additional data capture, see WebLink and Additional Order Fields.
Payment considerations
If your checkout flow includes payment collection, confirm that the correct payment processor and currency configuration are in place.
Before launch, test:
- the payment methods available to the learner
- currency behavior
- the final booking result after payment or confirmation
If the learner journey involves internal booking follow-up or invoice-based handling, also verify the downstream booking behavior in Administrate.
For the booking-side view of payment handling, see Booking Payments and Invoices.
Where checkout fits in the storefront journey
The Checkout Widget usually sits between training selection and booking confirmation.
That means it depends on the upstream storefront configuration being correct. If the learner reaches checkout with the wrong course, the wrong currency, or incomplete order information, the problem often begins earlier in the catalog or product setup.
For that reason, the checkout experience should always be reviewed as part of the full learner journey rather than as an isolated widget.
Testing the checkout widget
Before going live, test the entire flow using a real storefront page.
- Open the page containing the catalog or selection widget.
- Select a course or event.
- Proceed into checkout.
- Confirm the correct training item, learner details, and price appear.
- Complete the booking or payment flow.
- Verify that the resulting booking is created correctly in Administrate.
- Confirm any communications or confirmations are sent as expected.
This test matters because checkout problems often do not become obvious until the booking is actually created.
Common issues
Checkout does not load
- Confirm the shared WebLink script is present on the page.
- Confirm the widget container is present and correctly configured.
- Confirm the page is using the correct portal address and setup.
The wrong item appears in checkout
- Confirm the learner reached checkout from the correct catalog or event selection.
- Confirm filters and product setup are correct.
- Confirm the widget configuration is not pulling the wrong item context.
Order data is incomplete
- Confirm required fields are configured.
- Confirm any additional order fields are available in the checkout flow.
- Confirm the downstream booking workflow can accept the resulting order data.