web
You’re offline. This is a read only version of the page.
close
Skip to main content

Announcements

No record found.

News and Announcements icon
Community site session details

Community site session details

Session Id :
Microsoft Dynamics AX (Archived)

Payment Processor Dynamics 365 for Retail

(0) ShareShare
ReportReport
Posted on by 2

I'm working on implementing a new payment processor for our Microsoft Dynamics 365 for Retail eCommerce application and have a couple of questions about how to best integrate this. When looking at the docs it seems the IPaymentProcessor interface and the CRT payment handling is quite credit card focused. However, many of the modern payment providers does not only offer card payments but rather works as an "umbrella provider" for a wide range of global and local payment methods such as (card, invoice, bank, Swisch (Sweden), Vipps (Norway) etc.

None of the standard Payment methods that are setup in the Dynamics 365 for Retail really seems applicable for this type of payment provider. Does it make sense to create a new Retail Operation (Tender type) and payment method for this type of payment? Or is it better to try to fit it into one of the current methods/workflows?

When looking into the SubmitOrderRequestHandler work flow in the CRT I can see that the authorization is not actually made until the order is placed and sent to Retail Server/CRT. This workflow doesn’t really make sense to a payment provider like this (The typical approach would be to have the eCommerce Storefront initiate the authorization and pass on the order to Retail Server once the authorization is verified). This is because most payment providers issues a call back ones the payment is completed.

Also, looking into the CRT it seems that the default implementation of the SubmitOrderRequestHandler will look at the Tender type and if the type is set to 201 (PayCard) it will issues an AuthorizeTokenizedCardPaymentServiceRequest. However, if the tender type is set to anything else (Cash, Loyalty, and Gift Card etc.) the workflow will simply call Authorize immediately followed by a capture request. As far as I see it none of these workflows really fit a payment provider that don’t necessarily handle a card payment. There are validations made on the request that verify the TokenizedCard contains all necessary information but in this case we probably can’t even create a TokenizedCard since we simply don’t have the information. Using another tender type is problematic because of the immediate call to Capture.

I’d really appreciate if someone has some more insight on this subject and could point me in the right direction. Are there any guide lines for these scenarios?

*This post is locked for comments

I have the same question (0)

Under review

Thank you for your reply! To ensure a great experience for everyone, your content is awaiting approval by our Community Managers. Please check back later.

Helpful resources

Quick Links

Introducing the 2026 Season 1 community Super Users

Congratulations to our 2026 Super Stars!

Meet the Microsoft Dynamics 365 Contact Center Champions

We are thrilled to have these Champions in our Community!

Congratulations to the March Top 10 Community Leaders

These are the community rock stars!

Leaderboard > 🔒一 Microsoft Dynamics AX (Archived)

#1
CP04-islander Profile Picture

CP04-islander 26

#2
imran ul haq Profile Picture

imran ul haq 8

#3
André Arnaud de Calavon Profile Picture

André Arnaud de Cal... 4 Super User 2026 Season 1

Last 30 days Overall leaderboard

Featured topics

Product updates

Dynamics 365 release plans