Brian Shook Principal Program Manager

At POS, the order total in a transaction for a return is tracked in as a whole total, without strict method-to-method mapping of subtotals used from original payment methods (outside of linked refunds for credit cards). When creating a return, all relevant allowed payment methods used from orginating payments will be displayed for cashier return options. Once a subtotal is paid out on the return, the remaining balance options will still show all allowed originating payment methods for the return remaining balance. This idea is for the strict return enforcement for all payment method types, tracking per originating payment method total. 

Example: If a check is allowed to refund to either check or cash options, and a total is paid for by cash, card, and check subtotals- if the refund accounts for cash + check balance to be paid back by cash (as an allowed method); the remaining subtotal for the card originating balance cannot also be paid back by cash unless cash is set as an allowed return payment method for card also.

Adding support for WeChat Pay via Adyen Payment Connector for online and POS payments.

Payment Captures are an Asynchronous process. Calls to capture against the payment gateway receive a successful response that the capture request was made, but do not know if the issuer may decline capture at a later time as the capture request is processing.

Dynamics 365 checks the authorization status just before the capture request is made. A capture is then assessed in the Dynamics 365 Commerce system as 'successful' even though it may fail at a later moment. Although capture failures are rare, in the case of a later capture failure occurring- the Sales Order payment line is already set to 'Paid' and unable to be edited.

This idea is to add a function in Call Center to edit the Sales Order for a new payment entry/capture request in the case a capture failure is found during reconciliation. The previous payment line will return to a 'capture failed' or 'submitted' state- allowing the capture to be re-called or new payment line entered to collect payment.

This feature would allow for assigning the channel 'currency' payment method to load a dedicated 'exchange rate type' profile for the Point-of-Sale (POS) 'currency' transaction payment method. Current POS behavior loads at an environment level from the Commerce Shared Parameters > General > Exchange rate type field. With this feature, the channel-specific 'exchange rate type' can be set if needing for a dedicated store/channel; and the Commerce Shared Parameter exchange rate type will work as a fallback profile if not defined on the channel level.

Currently, the terminal lock occurs the moment in POS when a cashier selects the 'transaction' button. Initiation of the transaction will hold a lock state for POS and the attached terminal. For stores with a shared hardware stations and multiple POS stations interacting with a single terminal- a secondary POS station is locked out from initiating its own transaction.

This feature would move the terminal lock to an event later in the transaction process, potentially upon the payment method selection. This would allow a longer opportunity to build the transaction on differing stations (example, customer is choosing multiple products and adding to the transaction as they view and discuss) without locking out the single terminal for the 'other' POS station. This will free up multiple POS stations to build transactions and only locking the terminal during the payment interactions during the checkout process.

This capability would allow setting order thresholds to perform immediate capture of funds for a payment. Conditional settings may be:

• Order total threshold - large order total setting to send an immediate capture request following authorization success.
• Card Type setting - A capture request is sent as the card type is identified from the payment method (as some types expire authorizations at a different duration than others).
• Shipping Method condition - a shipping method that denotes a long-running ship time, setting on the ship method would prompt immediate capture.
• Product level - product items that may follow non-standard delivery protocol (longer running delivery times, specialized delivery, common low inventory).

This idea is to gauge interest in Commerce adding configurations to set immediate capture against the payment gateway. Not all suggestions above may be included in final feature; other suggestions also welcome for consideration for this feature.)

The current system payment form in Dynamics 365 Commerce and F&O utilizes a selection of the Payment method number, type, and then requires selection or entry of the card type for the customer. The selection list shows all card types associated to the customer, despite that some of these types may differ from the selected payment method information selected. An example is you may select the "MASTER" payment method, and are shown "Master" and "Visa" card types in the Number selection list due to the differences in these field's usage within the system.

This idea is to redesign the payment form in Headquarters for more efficient payment method entry, and where that design may allow customer cards on file to be selected, filter those results appropriately if a payment method is pre-selected in the form.

This idea is to continue to track demand for supporting Klarna within Commerce. Klarna will be available through Adyen, with support for notification webhooks, on POS and Online channels.

When a prepayment is made against a Sales Order, the payment is logged in the configured prepayment journal. When a refund is processed against this payment, the refund transaction is logged against the general configured journal. This idea would allow for an environment configuration direct the refund transaction to be logged in the prepayment journal (if balancing against the originating journal for prepayments).

To use when 'financial reconciliation in store' and 'cash traceability' are both enabled, this idea allows store managers to modify (update) or revert (remove) a cash movement event during the reconciliation process. The store manager can review blind-closed shifts and make adjustments as needed to help correct erroneous entries (due to entry mistakes by the shift owner). Scenarios may be:

• Shift A has done a Safe drop, Bank drop, Float entry, or Tender Removal but has a typo in their amount
• Shift B or Safe entry has failed to record money received from Shift A
• Start amounts can be overridden to account for mistaken count or declaration

This idea also suggests reviewing potential for differential journal/voucher posts for an adjustment pattern, so that financial postings follow balancing patterns (with either differential post or balancing total amounts needed to correct for mistaken entries).