Dynamics 365 Commerce Payment Profiles: Control POS Tender Visibility and Display Order

According to Microsoft Learn's release plan and product documentation, the feature entered public preview on April 3, 2026, and reached general availability on June 30, 2026. Microsoft's AI at Work roadmap now lists the capability as launched for Worldwide (Standard Multi-Tenant) cloud environments on the web platform, enabled by administrators, makers, or analysts for end users. Note that as of October 2026, Microsoft archived its standalone Dynamics 365 release plan pages and consolidated ongoing tracking into the unified AI at Work roadmap, where dates and rollout details always remain subject to change.

Why Register-Level Payment Profiles Matter​

In a modern retail store, not all checkout stations are created equal. A full-service counter or customer service desk might handle cash, paper checks, gift cards, and credit cards. Meanwhile, an express lane, a self-checkout kiosk, or a roving associate carrying a mobile device with Tap to Pay cannot physically accept coins, banknotes, or paper checks.

Before payment profiles were introduced, administrators faced three persistent operational headaches:

• Irrelevant Tender Clutter: Cashiers and self-checkout shoppers were presented with payment methods that the physical register hardware could not actually process.
• Rigid System Sorting: Because the system dictated the display sequence of payment options, stores could not natively float their most common tenders to the top of the list to save taps during peak hours.
• Undeletable Legacy Tenders: In Dynamics 365 Commerce, once a payment method has historical transactions tied to it, the system prevents administrators from deleting it. Hiding retired tender types from the POS screen previously required custom code extensions.

By introducing reusable payment profiles in Commerce headquarters, Microsoft lets administrators curate which tenders appear and in what sequence on a per-register basis—eliminating custom code maintenance and preventing configuration drift across stations.

Section Summary: Payment profiles decouple register-level tender display from the broad store-level configuration, allowing retailers to tailor payment menus to specific hardware capabilities, prioritize popular tenders, and hide legacy payment options without custom development.

How to Configure and Assign Payment Profiles​

Setting up payment profiles is performed centrally in Commerce headquarters rather than inside the local Store Commerce client. Microsoft Learn's setup documentation outlines a four-part workflow covering profile creation, method selection, register assignment, and data synchronization.

1. Create the Payment Profile​

1. Sign in to Commerce headquarters.
2. Navigate to Retail and Commerce > Channel setup > POS profiles > Payment profiles.
3. Select New.
4. Enter a unique Payment profile number to identify the record.
5. Enter a descriptive Profile name that reflects the station role (for example, Mobile registers - Tap to Pay only or Self-Checkout Kiosks).

2. Add and Order Payment Methods​

1. On the Payment profiles page, locate the Payment methods subgrid and select Add.
2. Choose a payment method from the master list defined in Commerce headquarters. Repeat this step for every tender that should be visible on registers using this profile.
3. Optionally, enter an integer in the Display order field for each included payment method.
   • Store Commerce POS renders payment methods in ascending numerical order (a method set to 1 appears above 2).
   • Any payment method left without a Display order value is placed after all methods that have an explicit number assigned.

3. Assign the Profile to Registers​

While Microsoft's release-plan overview notes that reusable profiles help standardize groups of registers by register type (such as express lanes or service counters), the actual assignment in Commerce headquarters is performed on individual register records:

1. Go to Retail and Commerce > Channel setup > POS setup > Registers.
2. Open the target register record you want to configure.
3. In the General section of the register form, locate the Payment profiles field and select your newly created payment profile.
4. Select Save, and repeat the assignment for each register that should use the profile.

4. Synchronize Changes to the POS​

Creating and assigning a profile in headquarters does not immediately alter the live checkout screens on the sales floor. Administrators must run distribution schedule job 1090 (Registers) to synchronize the updated register configuration out to the POS databases. Until job 1090 completes, registers will continue displaying their previous payment options.

Section Summary: Administrators build payment profiles under POS profiles, order tenders using ascending integers, link the profile on the Registers form, and push the update to stores using distribution schedule job 1090 (Registers).

Critical Boundaries, Fallback Behavior, and Troubleshooting​

Even straightforward configuration features have architectural guardrails that can trip up an administrator during rollout. Keep these verified operational boundaries in mind when deploying payment profiles:

• Store Mapping Is Still Mandatory: Adding a payment method to a payment profile does not automatically enable that tender for a store. According to Microsoft Learn, a payment method will only appear at the POS register if it is also mapped to the store (channel) to which that register belongs. If you add a payment method to a profile and it fails to appear at checkout, verify the store-level payment method configuration first.
• How Hiding Legacy Tenders Actually Works: Microsoft's roadmap description mentions the ability to "hide previously used payment methods". In practice, there is no automatic history-sensing toggle. Instead, once you assign a payment profile to a register, only the methods explicitly listed in that profile are shown. By simply omitting an older, undeletable payment method from the profile, it disappears from the register UI while preserving historical transaction integrity in the backend.
• Safe Fallback Behavior: What happens if you deploy this feature gradually, or if an administrator clears the Payment profiles field on a register? Dynamics 365 Commerce handles this gracefully: any register without an assigned payment profile—or any register from which a profile is later removed—automatically reverts to the legacy fallback behavior, displaying all payment methods configured for the store in the default system-determined order.
• Troubleshooting Checklist:
  • New order or hidden tenders aren't showing up at the lane? Confirm that the profile is saved on the specific register record and that distribution schedule job 1090 (Registers) has been executed and synced.
  • A newly added profile tender is missing on screen? Check that the payment method is configured and active on the parent store/channel record.

For retail IT teams running Dynamics 365 Commerce, payment profiles replace brittle UI extensions with clean, supportable headquarters administration—keeping the checkout menu focused strictly on what each register is built to handle.