Adyen Payment Connector in D365 Commerce

 

Adyen Payment Connector in D365 Commerce 

(Things I Had to Learn the Hard Way)

📌 This post is Part 1 of my upcoming blog series: “What I Learned During a D365 Commerce Implementation.”

The goal of the series is to share real-world, implementation-proven tips from the field — not theory, but lessons from things that broke, surprised me, or forced last-minute fixes. Future parts of the series will include credit card settlement timing, Commerce database restore scenarios, and Entra ID configurations after backup.

Let me tell you how this went down.

We were close to go-live.
The Adyen UAT setup was done. Everything looked fine — payments working, test transactions clearing, and the merchant account was active.

Then the production configuration hit me like a freight train.
Things I hadn’t accounted for.
Steps I didn’t realize were different.
And issues I didn’t know even existed — until they showed up on mobile browsers.

This blog isn’t a manual. It’s not a polished guide.
It’s a battle-tested checklist of things I had to troubleshoot, mostly in fire-fighting mode, right before go-live. And hopefully, if you’re setting up Adyen with Dynamics 365 Commerce, this will save you the scramble.

1. Merchant Account Name is Case-Sensitive (Yes, It Matters)

The first issue?
A minor case mismatch between the merchant account name in Dynamics and what was set up in Adyen’s portal. That one letter difference broke the connection.

So make sure:

• The exact casing of the merchant account matches across Dynamics, the Adyen portal, and connector configs.
• Don’t assume "testmerchant" is the same as "TestMerchant" — because it isn’t.

2. UAT vs Production – It’s Not Copy-Paste

In UAT, you can:

• Skip the optional domain field
• Proceed without enabling PCI roles
• Skip compliance steps like SAQ-A
• Still test everything using Cloud terminals and API keys

But in Production, here’s what I walked into:

• That “optional” domain? Mandatory.
• SAQ-A? Must be submitted and approved before anything moves
• PCI roles? Adyen won’t enable the API PCI role until they see that SAQ-A
• If anything’s missing, payments will simply fail silently

Also, make sure to configure the origin URL of your ecommerce website properly in the Adyen dashboard — this origin must match what is tied to your store’s distribution group in Dynamics.

And a pro tip: start preparing for your Adyen live merchant account at least 2 weeks before go-live. This gives you enough time to:

• Submit the SAQ-A
• Wait for review and approval
• Ensure the PCI API role is enabled
• Conduct live payment dry runs

Lesson: UAT success doesn’t mean production will behave the same.

 3. SAQ-A Is a Real Step, Not Just Compliance Fluff

After we submitted the SAQ-A (Self Assessment Questionnaire – Type A), we got a response like:

"Your SAQ-A is now valid until xxxxx . D365 is now referenced in 2F. We’ve enabled the API PCI role for your merchant account."

Until that happened, none of the real transaction flows would fully work in production.

So yes, it’s just a document. But it unlocks critical configuration.

Start it early. And confirm it’s acknowledged.

4. iOS Safari + Apple Pay = Issue with Adyen iFrame

On iOS devices, the Adyen iFrame simply refused to load on Safari.
No error in Dynamics. No visible issue on desktop.
Just — nothing happening on mobile.

Turns out:

If Apple Pay is enabled on the same merchant account used for credit card payments on the online channel, the Adyen JS SDK throws a silent exception. The iFrame can’t render.

This was confirmed by Microsoft support and is a known limitation.

Workaround:

• Use separate merchant accounts for Apple Pay and standard card payments
• Keep Apple Pay out of the iFrame flow
• Configure Apple Pay on channels that support it directly (e.g., mobile wallet or native apps)

If your online store uses the standard Adyen iFrame — and you’ve enabled Apple Pay on the same account — you’ll almost certainly hit this.

 

🔹 5. My Checklist Going Forward

✅ Item	UAT	Production
Case-sensitive merchant name	✔️	✔️
Optional domain	❌	✔️ Required
SAQ-A Required	❌	✔️ Mandatory
API PCI role (Adyen side)	❌	✔️ Only after SAQ-A
Cloud terminal setup	✔️	✔️
iFrame + Apple Pay (same merchant)	Possible	❌ Not supported on iOS
Origin URL configuration	Optional	✔️ Must match store site

This blog isn’t written from a perfect implementation.
It’s written from the chaos of prepping for go-live, discovering what works, what breaks, and what no one tells you up front.

So if you’re setting up Adyen payments in D365 Commerce — especially the online store — give this a once-over.
Because sometimes the smoothest payment flow is only one checkbox (or casing typo) away from not working.

    

Disclaimer: All opinions and experiences shared are my own and not affiliated with Microsoft or Adyen. Validate settings and compliance requirements with your respective partners.