How Checkout Is Built
The checkout page combines components from both Portal packages:- The managed
checkoutandcheckoutManagercomponents (Portal,FCORE_PORTAL) run the payment state machine and fire the actual payment. In Experience Builder these appear as FC Portal - Checkout Payment and FC Portal - Checkout Manager. Because they are managed, you configure them through their properties but cannot edit their code. - The unmanaged display shell (Portal Components) renders the Order details, summary, totals, and discount-code entry. In Experience Builder these appear as FS Portal - Checkout Details, FS Portal - Checkout Summary, FS Portal - Checkout Totals, and FS Portal - Checkout Discount Code. The display shell calls into the managed checkout engine to do the secure work.
How Checkout Finds the Order
The checkout page reads the Order it should display from a URL query parameter. You link a user to the checkout page with?orderId=<Order UUID> in the URL — the page reads that parameter to load the Order. Two optional parameters refine the flow: installmentId (the UUID of a specific Financial Event to pay) and payFullBalance.
Where Payment Sends the User Next
Thecheckout component’s Payment Confirmation URL property (paymentConfirmationPageApiName, default FC_Payment_Confirmation__c) sets the page the user is redirected to after a successful payment. Point this at the Experience page that holds your Payment Confirmation component.
Limitations and Common Pitfalls
- A missing
orderId(orinstallmentId) parameter shows an error, not a pay form. Linking to the checkout page without the URL parameter produces a Missing Order or Installment context message. Build your links so the Order’s UUID is always passed. - Checkout shows a notification instead of a pay form for non-payable Orders. This is by design. An Order that is in Draft, already Fully Paid, Voided, or Written Off — or whose price or tax calculation is still in progress (not yet Calculated) — cannot be paid. The same applies when there are no items, when a Financial Event is pending or needs action, or when discount-code items still need changes.
- Installment checkout can be blocked by a balance mismatch. When an installment amount does not match the balance due, installment checkout is blocked. This check is controlled by the
Portal_FE_MisMatch_Prevent_CheckoutConstant (enabled by default). - Guests cannot pay Orders that contain auto-charge items. A guest attempting to check out an Order with auto-charge items is blocked unless the
Allow_Guest_Payments_For_Auto_ChargeConstant is enabled (disabled by default). - Guest order access is controlled by Experience Cloud, not by fusionCore. The checkout components treat any guest user as having access to the Order, so a misconfigured guest-user profile or sharing setting can expose Orders. Lock down guest access through your Experience Cloud guest-user profile.
- Checkout components only render inside an Experience Cloud site. They will not appear on internal Lightning record or app pages.
Explore Checkout Configuration
Configuring the Business Unit's Portal Checkout URL
Set the Business Unit fields that build the checkout link placed on each Order.
Configuring Field Sets for Portal Checkout
Choose which Order and Financial Event fields appear at checkout, using Constant records and field sets.
Payment Confirmation
Configure the page checkout redirects to after a payment, including the receipt link.

