You’re offline. This is a read only version of the page.
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)
Share
Report
All responses (
Answers (
