#B2C Commerce21 utenti parlano di questo argomento

One thing to keep in mind is that embedding the HTML generated by Salesforce is usually the simplest approach if you just need the Web-to-Lead form on a WordPress page. You don't necessarily need a plugin for that. 

If you need more control over the form styling, field mapping, validation, or submission flow, then a custom WordPress implementation may be a better option.  

In that case, it's worth testing the lead creation and field mapping in Salesforce after embedding the form.

Hello @Palak Bohra

Please find url:

Fill out the form to get free trial org of Commerce cloud. 

Thank you

Hi @Mayra Janeth Gómez, in B2C Commerce you can include the price attribute as a standard attribute in your custom sorting rules (https://help.salesforce.com/s/articleView?id=cc.b2c_creating_sorting_rules.htm&type=5). The price attribute uses the information stored in your price books. So you could use a standard/base price book and a sales/promotional price book depending on how you create and structure your price books. Please note that promotional prices as a result of the promotion engine are not reflected in the sorting rules. Promotional prices based on our promotion engine are highly dynamic and are not considered in search to avoid performance impact.

@Giovanni Marchetto

, 

I don’t think a previous call is changing the POST to GET. This usually happens when the frontend code and controller route are not from the same SFRA version.

Since this started after upgrading from SFRA 6.0.0 to 6.2.0, I’d compare all ConsentTracking-related files, not just the controller.

Check these:

1. Search your cartridges for ConsentTracking-SetConsent, ConsentTracking-SetSession, and SetConsent.
2. See if your custom cartridge is overriding ConsentTracking.js or any consent popup JS/ISML.
3. Compare those files with the SFRA 6.2.0 version.
4. Clear cache and redeploy static assets.

Most likely, the browser is calling the newer GET-based consent endpoint, but your controller/custom override is still expecting POST. So it looks like a version mismatch rather than the method being overridden. 

Hi @Robert Musk

Salesforce Payments is available for sandbox environment or Salesforce payments only available in product environmen only, but how to test the salesforce payments in sanbox regarding payment capture, refunding , payment failures? can we able to cpature the authorized payment in stripe test account  

do you have any documentation about configuring and setuping the salesforce payment for stripe in sandbox ? 

Hi, 

You can trigger an

server-side campaign using the standard Event API structure — no special sandbox needed. 

Send a payload like this to your dataset’s Event API endpoint:

{
  "source": { "channel": "Server", "pageType": "Cart" },
  "user": { "id": "USER-123" },
  "itemAction": "ViewCart",
  "cart": {
    "complete": [
      { "itemId": "SKU-001", "quantity": 2, "price": 19.99 },
      { "itemId": "SKU-002", "quantity": 1, "price": 12.50 }
    ]
  }
}

Key points:

• Use "itemAction": "ViewCart" to activate the In Cart anchor.
• cart.complete should list products with itemId, quantity, and price.
• Make sure your itemId matches catalog IDs in Personalization Studio.
• Include "source": { "channel": "Server" } so server-side campaigns return messages in the response.

Reference: Event API | Marketing Cloud Personalization | Salesforce Developers

Hi @Marcha Sipkes

 The A/B test is set up via Merchant Tools > Online Marketing > A/B Testing in Business Manager. 

Please refer to the following help articles for additional details and setup guidance:

https://help.salesforce.com/s/articleView?id=cc.b2c_ab_test_comparing_search_sorting.htm&type=5

  https://help.salesforce.com/s/articleView?id=cc.b2c_setting_up_active_data_for_testing.htm&type=5

 https://help.salesforce.com/s/articleView?id=commerce.b2c_rn_create_active_data_sorting_rules.htm&type=5

 https://help.salesforce.com/s/articleView?id=cc.b2c_configuring_predictive_sort.htm&type=5

 Hope this helps. Thanks!

Your workflow is logically sound and people do run OMS this way, but you're using it slightly against the grain of how it was originally designed. A few things worth pressure-testing before you build further:

OMS's data model assumes Order Summaries originate from a Commerce storefront. Direct-sales Orders work, but Order Summary reprocessing (cancellations, partial returns, post-activation line edits) gets awkward because the flows assume a B2C return path. Map out your change-management scenarios early.

Work Orders aren't natively integrated with the Fulfillment Order lifecycle the way picking/packing is. You can bridge it with flows, but the handoff between "manufacturing complete" and "fulfillment ready to ship" is custom territory — make sure someone owns that state machine.

On the Commerce conflict question: yes, this is a real risk if both your direct orders and storefront orders feed the same fulfillment configuration. Order routing rules, inventory reservation, and shipment grouping can collide. The cleanest pattern I've seen is separate Order Delivery Group routing logic per channel, with a shared inventory layer underneath.

Net: not outside the intended use case, but you're at the edge of it. Worth doing a proper architecture review before the customizations compound.