To accept digital wallets in Dynamics 365, enable Enhanced wallet support under Workspaces > Feature management, then build the wallet configuration chain: create a Wallet card type, map it to your processor’s payment method, add that card type to your store’s payment methods, and turn on wallet acceptance with your payment service provider. Run the required distribution jobs and validate everything in a sandbox before touching production.

That’s the whole sequence at a glance. Before you open a single form, line up these checklist items:

• Confirm your Commerce version supports the wallet feature (10.0.45 or later avoids extra flighting).
• Identify which wallets your payment connector actually returns as distinct processor payment methods.
• Schedule a maintenance window for the 1110 and 1070 distribution jobs after configuration changes.

Pro Tip: Do a dry run in a sandbox environment first. Wallet mapping errors that surface in production usually trace back to a skipped propagation wait, not a broken connector.

Key Takeaways

Accepting digital wallets in Dynamics 365 requires enabling the wallet feature, creating mapped Wallet card types, and running the 1110 and 1070 distribution jobs before any channel will process a wallet transaction correctly.

Point	Details
Enable the feature first	Turn on Enhanced wallet support in Feature management, then run job 1110 before creating card types.
Map processors, not BINs	Wallets lack BIN ranges, so use processor payment method mapping to link connector values to Wallet card types.
Coverage varies by channel	Google Pay and Apple Pay often work POS and online; others may be card-present only, depending on the connector.
Use pay-by-link for gaps	Enable the Pay By Link input type to accept wallets in call center and field service scenarios.
Consider a connector for scale	Sensepass links ERPs, POS, and eCommerce to 100+ payment methods and 50+ processors when native coverage runs out.

Table of Contents

• Enable Wallet Payment Support and Create Wallet Card Types
• Why Processor Payment Method Mapping Is Required for Wallets
• Which Channels Actually Support Wallets Right Now
• Using Pay-by-Link to Cover Wallet Gaps
• Deployment and Testing Checklist Before Go-Live
• Common Configuration Gotchas and How to Fix Them
• Why a Processor-Agnostic Connector Matters for Wallet Coverage
• What I’d Actually Recommend
• When Native Wallet Support Isn’t Enough, Here’s the Next Step
• Sources

Enable Wallet Payment Support and Create Wallet Card Types

The setup process for digital wallet support in Dynamics 365 Commerce runs through Retail and Commerce headquarters, and it follows a specific order that Microsoft’s documentation lays out as a four-step configuration flow: enable the feature, create the card type, map the processor payment method, and turn the wallet on with your provider. Skip a step and the wallet button either won’t render at POS or will fail authorization silently.

Here’s the sequence in practice:

1. Go to Workspaces > Feature management and search for Enhanced wallet support. Enable it, then run the 1110 (Global configuration) distribution job so the feature propagates to your environment.
2. Navigate to Retail and Commerce > Channel setup > Payment methods > Card types and create a new card type. Set Type to Wallet, enter the Electronic payment name your processor uses, and specify the Issuer (Apple Pay, Google Pay, PayPal, and so on).
3. Add the new Wallet card type to your store’s Payment methods list so it’s assignable to a channel.
4. Confirm your PSP has wallet acceptance enabled on their end. A wallet card type configured in Dynamics does nothing if the processor account itself hasn’t turned on that method.

Before you start, verify the account running these steps has security roles that include Payment methods and Card types maintenance. Snapshot your sandbox environment beforehand. If a mapping goes sideways, restoring the snapshot is far faster than manually unwinding card type and payment method changes one by one.

Pro Tip: Name your Wallet card types consistently across environments (dev, test, production). Mismatched naming is the single most common reason config that works in sandbox breaks after go-live.

Why Processor Payment Method Mapping Is Required for Wallets

Card-based payments map to a card type using the BIN range on the card number. Wallets don’t have one. A tokenized Apple Pay or Google Pay transaction comes back from the processor with no BIN to inspect, which is exactly why Microsoft added a separate mechanism: processor payment method mapping. Instead of inferring the card type from the number, Dynamics 365 maps the connector’s raw processor payment method value (things like googlepay, alipay, or wechatpay_pos) directly to your configured Wallet card type.

The walk-through looks like this:

• Open the Card types form and select the Processor payment method mapping link.
• Review the list of unmapped processor payment methods your connector has reported.
• Add a mapping from each processor value to the correct Wallet card type.
• Verify the mapping saved and appears against the right store and legal entity.

Confirm your connector actually populates the PaymentMethodVariant field. If it doesn’t, wallet transactions can authorize successfully at the processor while Dynamics has no idea which wallet type to attribute them to, which breaks reporting and reconciliation. If PaymentMethodVariant is blank, update your payments SDK first, then recheck. Set a store-level default for unmapped processor payments so an unrecognized wallet doesn’t trigger a protective decline at checkout.

Which Channels Actually Support Wallets Right Now

Not every wallet works everywhere, and this is the part of the configuration that trips up teams who assume “enabled” means “enabled everywhere.” Native connector support varies by channel and by processor: Google Pay and Apple Pay generally work at both POS and online checkout, while wallets like Alipay, WeChat Pay, and several BNPL options are often restricted to card-present transactions depending on the connector you’re running.

A few practical notes worth building into your rollout plan:

• Google Pay online checkout typically runs through a dedicated Google Pay module, separate from the general payment express module used for other wallets. Confirm your CSP (Content Security Policy) headers allow the Google Pay domains, or the button silently fails to render.
• PayPal and similar express checkout patterns need a careful look under PSD2 rules in markets where strong customer authentication applies. An express flow that skips authentication steps can create declined transactions or compliance exposure depending on your region’s enforcement.
• Card-not-present wallet support for connectors like Adyen is documented per wallet type, not as a blanket yes/no, so check the connector’s own support table before promising a wallet to a specific channel.

Pro Tip: Build a one-page wallet support matrix for your own connector before rollout. It saves you from promising Alipay at online checkout when your connector only supports it card-present.

Using Pay-by-Link to Cover Wallet Gaps

When native wallet support doesn’t reach a channel, pay-by-link often closes the gap without waiting on a connector update. Dynamics 365 supports this as a dedicated payment input type, letting a call center agent or field rep send a payment link that opens a hosted checkout supporting whatever wallets the processor allows there.

Setting it up takes two steps:

1. On the Payment Input Type form, enable Pay By Link as an available input type for the relevant payment method.
2. Add your Wallet card types to the Pay By Link payment method configuration so wallets appear as options on the hosted page the customer receives.

Pay-by-link fits naturally in call center scenarios, field service jobs where a technician can’t run a card reader, and remote or phone-based transactions. Treat it as a preview-stage capability in some Dynamics releases, and check that your reconciliation process tags pay-by-link transactions distinctly, since they hit your ERP through a different capture path than in-person or online checkout.

Deployment and Testing Checklist Before Go-Live

Getting the configuration right in headquarters is only half the job. The changes need to reach your channels, and that means running the correct scheduler jobs in the correct order.

1. Deploy your connector package, typically a RetailDeployablePackage, through LCS. If your connector requires payment web files, place them in the e-commerce site’s root under ECOM.WebRoot/Connectors.
2. Run 1070 (Channel configuration) to push store and channel-level payment settings, then 1110 (Global configuration) for feature and card type changes.
3. Allow propagation time. Testing immediately after triggering these jobs is a common false alarm; a short wait avoids chasing a failure that isn’t actually there.
4. Run test cases covering POS QR code scanning, the online wallet authorization popup, a full pay-by-link flow, and how tokens behave on a repeat transaction.

Pro Tip: Log the exact timestamp you ran 1070 and 1110 in your deployment notes. If a tester reports a failure two minutes later, you’ll know immediately whether propagation timing, not configuration, is the culprit.

Common Configuration Gotchas and How to Fix Them

Most wallet configuration failures in Dynamics 365 trace back to a handful of repeat offenders, and they’re fixable in minutes once you know where to look.

• Missing PaymentMethodVariant: update the payments SDK version on the connector; an outdated SDK often won’t populate this field even when the wallet transaction itself succeeds.
• Unmapped processor payment method: set a store-level default mapping so unrecognized wallet values don’t trigger a protective decline at the point of sale.
• Feature not visible on older releases: Commerce versions before 10.0.45 may need an additional feature flight, such as one covering non-recurring credit card token flows, before wallet options appear.
• POS button confusion: the point-of-sale UI doesn’t let you map a specific wallet to a dedicated button the way card types display; staff need training on which generic prompt corresponds to which wallet.

Why a Processor-Agnostic Connector Matters for Wallet Coverage

Native connector support gets you moving fast, but it ties your wallet coverage to whatever that one connector’s roadmap decides to prioritize next. Sensepass approaches the problem differently: it’s a payment connector, the integration layer linking your ERP, POS, and eCommerce systems to 100+ payment methods and 50+ card processors through a single integration, rather than a single-processor connector you’re locked into.

• One integration point instead of separate connector work for every processor you add.
• Every transaction reconciles back into your ERP automatically, which matters more as wallet volume grows across channels.
• Processor-agnostic architecture means adding or swapping processors doesn’t require rebuilding your wallet mapping from scratch.

Pro Tip: If you’re already juggling more than one connector’s wallet support table, that’s usually the signal it’s time to look at a connector layer instead of another one-off mapping project.

What I’d Actually Recommend

Start native. Get the wallets your customers actually ask for working through Dynamics 365’s built-in configuration, and lean on pay-by-link for the channels where native support falls short. Only bring in a processor-agnostic connector once you need fast region expansion, multiple processors, or you want to own your tokens outright. Set testing milestones before go-live either way. That discipline matters more than which path you pick.

— Vlad

When Native Wallet Support Isn’t Enough, Here’s the Next Step

If you’ve worked through the mapping tables, the connector limitations, and the channel gaps above and you’re still short on wallet coverage, that’s usually a sign the constraint is the connector, not your configuration. Sensepass is a payment connector, not a payment orchestration platform, built to link the ERP, POS, and eCommerce systems you already run (including Microsoft Dynamics 365, Business Central, Finance & Operations, and Commerce) to more than 100 payment methods and 50+ card processors through one integration.

That includes the wallets covered in this guide (Apple Pay, Google Pay, PayPal, Venmo, Alipay, WeChat Pay, Amazon Pay), along with BNPL options like Klarna, Afterpay, and Sezzle, and pay-by-bank methods including Trustly and ACH, all routed through a connector that’s processor-agnostic by design. Every transaction still reconciles back into your ERP, and because you own your payment tokens, adding a new processor later doesn’t mean rebuilding your integration. If you’re evaluating whether your current connector can scale with you, view how the connector works or request a technical walkthrough to see how wallet mapping looks on Sensepass compared to what you’ve configured natively.

Recommended

• How to accept digital wallets: boost retail sales 52% – Omnichannel payments at the Point Of Sale | Sensepass
• The Easiest Way to Integrate FreedomPay and Microsoft Dynamics 365