Question 1
Choose 1
While working on a commerce rollout, a developer needs to update the checkout process
so that buyers can purchase with one of the below payment types.
• Credit Card
• Purchase Order
• Contract Now & Pay Later
Additionally, the developer needs to show only Purchase Order and Contract Now & Pay Later if a custom checkbox field on the account is checked.
How should the developer meet these requirements?
• Credit Card
• Purchase Order
• Contract Now & Pay Later
Additionally, the developer needs to show only Purchase Order and Contract Now & Pay Later if a custom checkbox field on the account is checked.
How should the developer meet these requirements?
Correct answer:
B. Create a custom Lightning web component for the checkout flow that has all the options
available. Within that component, pull data from the account to determine which options to
show.
Explanation:
In modern Salesforce B2B Commerce (especially LWR/Lightning Experience storefronts using Lightning Web Components), the checkout process is highly customizable through custom LWCs placed on the Checkout page or within custom checkout flows. The standard payment component handles core payment processing (like credit cards via Salesforce Payments or integrated gateways), but for non-standard or conditional payment types like Purchase Order (PO) and a custom "Contract Now & Pay Later" (likely a deferred payment or invoicing option tied to contracts), you need more control.
Purchase Order is natively supported in B2B Commerce (often via the dual payment component or PO-specific handling), but "Contract Now & Pay Later" is not a standard out-of-the-box payment type—it's custom logic. Conditional visibility based on a custom checkbox field on the Account (e.g., Allow_Deferred_Payment__c) requires querying the effective Account record (via the cart's associated buyer/account) and dynamically showing or hiding options.
Why B is the Best Approach:
A custom LWC for the payment/checkout section can:
Display all three options (Credit Card via standard integration, PO as a radio or checkbox option, and custom "Contract Now & Pay Later" as another selectable option).
Use @wire with Lightning Data Service (or imperative Apex if needed) to fetch the Account record and check the custom checkbox.
Conditionally render the PO and "Contract Now & Pay Later" options only if the checkbox is true.
Handle selection logic, validation, and pass the chosen payment type to the checkout flow (for example, via custom properties or events to update the cart or order).
This approach is declarative where possible but allows full programmatic control for complex conditions tied to Account data, which is not natively supported in standard payment components or simple screen flow visibility rules for payment options.
Why the Other Options Are Incorrect:
A — Using pub-sub with the standard payment component is possible for some interactions, but the standard payment component does not natively expose events for conditionally adding or showing non-standard payment types like "Contract Now & Pay Later." It is not the cleanest or recommended way for full control over the UI and logic.
C — Screen flows in B2B Commerce checkout support expression-based visibility rules, but the standard payment component does not allow adding arbitrary new payment methods (like "Contract Now & Pay Later") through configuration alone. Visibility rules work for hiding or showing entire components or fields, but not for dynamically filtering options inside the built-in payment UI. PO is supported, but custom types require extension.
D — Adding a new payment gateway (via reference implementations like Adyen, Stripe, etc.) is intended for processor integrations (such as credit card variants), not for non-gateway methods like PO or custom deferred payments. PO does not use a gateway, and "Contract Now & Pay Later" is not a gateway-based method.
References:
Salesforce Help: "Customize the Payment Section of Checkout in a Commerce Store" — Recommends custom LWCs for advanced payment UI and processing beyond standard Salesforce Payments.
B2B Commerce Developer Guide: Custom checkout component examples (such as a Terms and Conditions LWC) demonstrate how to build and extend checkout sections with conditional logic.
In modern Salesforce B2B Commerce (especially LWR/Lightning Experience storefronts using Lightning Web Components), the checkout process is highly customizable through custom LWCs placed on the Checkout page or within custom checkout flows. The standard payment component handles core payment processing (like credit cards via Salesforce Payments or integrated gateways), but for non-standard or conditional payment types like Purchase Order (PO) and a custom "Contract Now & Pay Later" (likely a deferred payment or invoicing option tied to contracts), you need more control.
Purchase Order is natively supported in B2B Commerce (often via the dual payment component or PO-specific handling), but "Contract Now & Pay Later" is not a standard out-of-the-box payment type—it's custom logic. Conditional visibility based on a custom checkbox field on the Account (e.g., Allow_Deferred_Payment__c) requires querying the effective Account record (via the cart's associated buyer/account) and dynamically showing or hiding options.
Why B is the Best Approach:
A custom LWC for the payment/checkout section can:
Display all three options (Credit Card via standard integration, PO as a radio or checkbox option, and custom "Contract Now & Pay Later" as another selectable option).
Use @wire with Lightning Data Service (or imperative Apex if needed) to fetch the Account record and check the custom checkbox.
Conditionally render the PO and "Contract Now & Pay Later" options only if the checkbox is true.
Handle selection logic, validation, and pass the chosen payment type to the checkout flow (for example, via custom properties or events to update the cart or order).
This approach is declarative where possible but allows full programmatic control for complex conditions tied to Account data, which is not natively supported in standard payment components or simple screen flow visibility rules for payment options.
Why the Other Options Are Incorrect:
A — Using pub-sub with the standard payment component is possible for some interactions, but the standard payment component does not natively expose events for conditionally adding or showing non-standard payment types like "Contract Now & Pay Later." It is not the cleanest or recommended way for full control over the UI and logic.
C — Screen flows in B2B Commerce checkout support expression-based visibility rules, but the standard payment component does not allow adding arbitrary new payment methods (like "Contract Now & Pay Later") through configuration alone. Visibility rules work for hiding or showing entire components or fields, but not for dynamically filtering options inside the built-in payment UI. PO is supported, but custom types require extension.
D — Adding a new payment gateway (via reference implementations like Adyen, Stripe, etc.) is intended for processor integrations (such as credit card variants), not for non-gateway methods like PO or custom deferred payments. PO does not use a gateway, and "Contract Now & Pay Later" is not a gateway-based method.
References:
Salesforce Help: "Customize the Payment Section of Checkout in a Commerce Store" — Recommends custom LWCs for advanced payment UI and processing beyond standard Salesforce Payments.
B2B Commerce Developer Guide: Custom checkout component examples (such as a Terms and Conditions LWC) demonstrate how to build and extend checkout sections with conditional logic.