This is the multi-page printable view of this section. Click here to print.
Integrate your Manhattan Active Solution with common third party services such as tax calculations, promotions, and payment processing. Additional capabilities beyond what is available in the existing apps can be addressed by the services project team.
Please select a category from the list below for a summary of functionalities within the category. Within each category, select the third party vendor to understand what app functionalities are currently available.
Manhattan Active Omni solutions provide clients the ability to manage the payment processing of an order paid for with alternative payment methods to traditional credit card and gift cards, such as buy now and pay later or secure digital wallets. Throughout the life cycle of each order, MAO uses the token information for the alternative payment method to process authorizations, settlements, and refunds through integration with the 3rd party payment gateway.
Manhattan Active Omni has pre-built apps with many 3rd party Alternative Payment Gateways for one or more of the above functionalities which can be leveraged out of the box. Please see each 3rd party vendor to view what functionalities are available.
Afterpay is a payment processor which enables retailers to offer their customers the option to place an order now and pay in four installments with one installment due on order placement.
Manhattan Active Omni is not integrated with Afterpay out of the box. This integration enables communication with Afterpay version 2 by altering the base functionality in the following ways:
Manhattan Active Omni sends a capture request to Afterpay after a quantity is shipped for the shipment invoice amount. For split shipments, Manhattan Active Omni sends multiple capture requests against the single initial authorization and the order’s Afterpay transaction ID.
Manhattan Active Omni sends a refund request to Afterpay in the cases of return order creation after the entire authorization is captured as well as appeasements/adjustments created after the entire authorization is captured. Afterpay supports full or partial refunds against the order’s Afterpay transaction ID.
Manhattan Active Omni sends a void request to Afterpay in the case that the order is cancelled, or the order completes with a final order total lesser than the initial order total. Afterpay only supports a full void of the remainder of an authorization, therefore the void amount is always sent for the difference between the initial and final order totals (which is $0 in the case of an order cancellation).
Manhattan Active Omni sends the shipping details to Afterpay as items ship using the Update Shipping Courier API, which allows Afterpay to provide better customer service.
Amazon Pay is an industry-leading payment solution that integrates with order creation host systems to handle payment processing for specific tenders. Amazon Pay is a commonly used online payment processing service that is owned by Amazon. Amazon Pay gives customers the option to pay with Amazon accounts on external merchant websites.
Manhattan Active Omni is not integrated with Amazon Pay out of the box. This integration enables communication with Amazon Pay using ILS Core version 6.05 by altering the base functionality in the following ways:
This integration does not include Authorization or Void transactions and Amazon Pay is not an available payment tender through Manhattan Active Omni call center (imported orders only).
MAO generates an Advanced Authorization synchronous call to Amazon Pay in the event of a split shipment. Amazon Pay accepts only one settlement record per authorization. Therefore, if a split shipment occurs and is settled in the same day, MAO obtains a new authorization for the remaining amount for that payment tender on the order.
MAO generates synchronous settlement requests to Amazon Pay, in the Amazon Pay expected format, for open shipment invoices requiring capture. MAO is responsible for receiving the response and updating the payment transaction appropriately.
MAO generates synchronous refund requests to Amazon Pay, in the Amazon Pay expected format, for open refund invoices (for returns and appeasements) requiring capture. MAO is responsible for receiving the response and updating the payment transaction appropriately.
In the event Amazon Pay initially sends MAO a capture or refund pending response, Amazon Pay later sends an asynchronous message containing the final transaction decision. This message is passed to MAO in JSON format, with the expectation that it is translated by a middleware. MAO is responsible for consuming the JSON message from a MAO queue and updating the payment transaction appropriately.
Klarna is a payment provider that allows customers to pay for orders in installment plans.
Manhattan Active Omni is not integrated with Klarna out of the box. This integration enables communication with Klarna by altering the base functionality in the following ways:
MAO generates synchronous settlement requests to Klarna, in the Klarna expected format, for open shipment invoices requiring capture. MAO is responsible for receiving the response and updating the payment transaction appropriately.
When the order is cancelled prior to any part of it being shipped, Active Omni generates a cancellation call to Klarna.
Release Authorization transactions occur anytime the remainder on the order has been cancelled after an initial capture is received. When the remaining unshipped order is cancelled, an authorization reversal transaction is generated. If this transaction amount is equal to the remaining to be paid, a void transaction is generated to Klarna to inform that this amount is no longer due by the customer.
MAO generates synchronous refund requests to Klarna in the Klarna expected format, for open refund invoices (for returns and appeasements) requiring capture. MAO is responsible for receiving the response and updating the payment transaction appropriately.
PayPal is an online payment platform that facilitates payments between individuals and businesses.
Fueled by a fundamental belief that having access to financial services creates opportunity, PayPal (NASDAQ: PYPL) is committed to democratizing financial services and empowering people and businesses to join and thrive in the global economy. Our open digital payments platform gives PayPal’s 325 million active account holders the confidence to connect and transact in new and powerful ways, whether they are online, on a mobile device, in an app, or in person.
This integration enhances the current MAO out of box integration with PayPal as follows:
This integration implements additional functionality for Manhattan Active Omni (MAO) Point of Sale (POS) & ECOM / Call Center card payment flows with PayPal’s payment platform. The features include:
PayPal is used as a payment method for placing an order on the retailer’s website. During the order creation, an authorization is performed by the merchant that applies a hold on the buyer’s funds which is typically valid for 29 days. PayPal allows settlement i.e., capturing less than the original authorization, full authorization amount, or even more than the authorization amount (up to 115% of the original authorization or $75 USD more, whichever is less).
However, during the order lifecycle if an order edit results in the full or partial authorized amount being voided then the funds can be released via a DoVoid call to PayPal.
MAO provides an out of box integration with PayPal using REST Service APIs for Signature and Certificate mode to process the payment transactions for Settlement and Refund. However, during scenarios when order edits result in the authorized amount being reversed to the buyers account, base MAO generates an authorization reversal transaction but does not send it to PayPal, or any Payment Gateway out of the box as a result of which the customer amount is held and unavailable for use till the authorization expires.
This feature adds the ability for MAO to send a PayPal DoVoid call to reverse (releases) complete or partial authorization amount on the buyer’s account when an authorization reversal is generated.
For PayPal, an authorization places a hold on the funds and is valid for 29/90 days. After a successful authorization, PayPal recommends that you capture the funds within the honor period. Success of the capture is subject to risk and availability of funds on the authorized funding instrument.
Within the 29/90-day authorization period, a client can issue multiple re-authorizations after the honor period expires. A re-authorization generates a new authorization ID and restarts the honor period, and any subsequent capture should be performed on the new authorization ID. This feature adds logic for MAO to send the reauthorization API to PayPal.
This feature allows the POS application to process card present payment capture (settlement) for Pay & Carry lines and card not present payment authorization for Save the Sale lines with a single swipe of a credit card.
Refunds are executed in MAO to process returns or negative exchanges. The Follow-on Refund, or Referenced Refund, refunds the original card that was used to execute the sale without the card being present. This applies to both POS and Call Center flows.
Refund by Card Entry, or Unreferenced Refund, refunds the card that is entered in the payment terminal via insert, tap or swipe, at the time of the transaction being executed. This flow applies only to POS not Call Center.
This feature allows the store user to void or cancel a partial card payment applied to a POS transaction.
This feature allows the POS application to reverse payments captured for a Pay & Carry Sale transaction that was completed and later post voided. Post Void is permitted only on the same business day as the original Sale.
This feature allows POS to determine and record the result of an abandoned payment in order for the Cancel Order process to reverse it. Cancel Order process reverses any payments that were captured for orders that are eventually voided.
This feature allows the Contact Center application to capture a credit card payment method for an order which upon confirmation of the order is used to Authorize payment for that order. Card information is entered on an iframe that is hosted on the PayPal gateway and is tokenized by PayPal before returning to MAO.
This feature allows MAO to Authorize funds for an order using a tokenized payment method. The funds authorized are to be captured upon fulfilment.
This feature allows MAO to obtain a new authorization in scenarios where a previous authorization expires before funds are captured for the same.
This feature allows the POS application to leverage an existing credit card payment method to complete a card not present charge for Pay & Carry orderlines added in-store to a BOPIS order upon fulfilment.
Manhattan Active Omni solutions provide clients the ability to verify entered addresses across Manhattan solutions to prevent bad data and to ensure timely delivery by leveraging integration with an external Address Verification Service provider.
Manhattan Active Omni has pre-built apps with many 3rd party AVS providers which can be leveraged out of the box. Please see each 3rd party vendor to view what functionalities are available.
Avalara is an industry-leading tax solution that integrates seamlessly with host systems to handle all tax calculation needs for eCommerce.
Manhattan Active Omni is not integrated with Avalara out of the box. This integration enables communication with Avalara by altering the base functionality in the following ways:
This feature adds integration with Avalara from Manhattan Active Omni to validate addresses entered in the Point of Sale and Contact Center applications. This support is provided for any address values that are entered initially or edited by the Point of Sale or Contact Center modules.
When a user adds or modifies an address in the Manhattan Active Omni Contact Center or POS, a web service call is made to Avalara AVS containing the address information captured by the UI. A response is received from Avalara AVS that indicates whether the address that was entered can be fully verified or if recommended address(es) are present as alternatives. These values, if returned, are displayed to the user in the UI for confirmation.
This feature is not extended to include other values that may be offered during verification such as email addresses or billing addresses. This feature is also not applied to orders interfaced into Manhattan Active Omni from external systems
Experian QAS is an address verification and email verification vendor who provides services to enable verification of customer shipping addresses and emails to ensure accurate data. This module provides integration with this vendor tool to augment the Manhattan Active Omni system and enable these verifications.
Manhattan Active Omni is not integrated with QAS AVS out of the box. This integration enables communication with QAS AVS by altering the base functionality in the following ways:
This feature is not extended to include other values that may be offered during verification such as billing addresses. This feature is also not applied to orders interfaced into Manhattan Active Omni from external systems.
When a user adds or modifies an shipping address in the Manhattan Active Omni Contact Center or POS, a web service call is made to Experian QAS containing the address information captured by the UI. A response is received from Experian QAS that indicates whether the address that was entered can be fully verified or if recommended address(es) are present as alternatives. These values, if returned, are displayed to the user in the UI for confirmation.
When the CSR/User adds or edits email address on the customer order through Manhattan Call Center UI or through Manhattan Customer Engagement UI, a web service call is made to Experian QAS containing the email address information captured by the UI. A response is received from Experian QAS that indicates whether the email address that was entered was verified or not. If the Experian QAS system is unable to verify the email address or if it is incorrect, an error is displayed on the Manhattan UI confirming that the email address was not verified or is incorrect. User can then edit the email address or ignore and proceed
Loqate is an address verification vendor and leading specialist for location data. Their solutions provide customers with the capability to verify addresses at the point of capture via API and cleanse customer data via batch processing. The global API covers 130 address formats, 3000+ languages, and 245 countries and territories.
Manhattan Active Omni is not integrated with Loqate AVS out of the box. This integration enables communication with Loqate AVS by altering the base functionality in the following ways:
Verification for imported order addresses, billing addresses, phone numbers, and email addresses are not supported within this feature.
When a user adds or modifies a shipping address in the Manhattan Active Omni Contact Center, a web service call is made to Loqate containing the address information captured by the UI. A response is received from Loqate that indicates whether the address that was entered can be fully verified or if a recommended address is present as alternative. When the Loqate cleanse API returns one or more results, the address pop-up is shown. When multiple addresses are returned in the web service response with acceptable data match scores, the Call Center user is presented with the option to select between the original address and the highest quality address match from Loqate. If the API request is not successfully processed to Loqate, or if a response is returned with an error code or an indicator that the address does not meet necessary verification standards, the AVS pop-up displays with failure message. No recommended address is provided in these failure scenarios
Strikeiron Address Verification (acquired by Informatica) is the only service that combines postal certifications in one engine from all six global postal organizations: USPS, Canada Post, La Poste in France, New Zealand Post, Australia Post, and Eircode in Ireland. It’s able to parse, analyze, verify, correct, and format addresses according to local postal standards—ensuring that correct elements appear in the appropriate hierarchical alignment. Only with the right address format can you be sure a mailing gets to its addressee.
Manhattan Active Omni is not integrated with Strikeiron AVS out of the box. This integration enables communication with Strikeiron AVS by altering the base functionality in the following ways:
This feature is not extended to include other values that may be offered during verification such as billing addresses. This feature is also not applied to orders interfaced into Manhattan Active Omni from external systems.
When a user adds or modifies an shipping address in the Manhattan Active Omni Contact Center, a web service call is made to Strikeiron containing the address information captured by the UI. A response is received from Strikeiron that indicates whether the address that was entered can be fully verified or if recommended address(es) are present as alternatives. These values, if returned, are displayed to the user in the UI for confirmation
UPS Address Validation System APIs enable Manhattan Active Omni to check a customer’s address and provide suggested alternatives if an error is discovered. This helps the clients reduce operating costs and improve customer service by primarily reducing the chances of mis-shipped orders.
Manhattan Active Omni is not integrated with UPS AVS out of the box. This integration enables communication with UPS AVS by altering the base functionality in the following ways:
This feature is not extended to include other values that may be offered during verification such as billing addresses. This feature is also not applied to orders interfaced into Manhattan Active Omni from external systems.
When a user adds or modifies an shipping address in the Manhattan Active Omni Contact Center, a web service call is made to UPS containing the address information captured by the UI. A response is received from UPS that indicates whether the address that was entered can be fully verified or if recommended address(es) are present as alternatives. These values, if returned, are displayed to the user in the UI for confirmation
Manhattan Active Omni solutions provide clients the ability to manage the payment processing of an order paid for by credit card . The card number must be tokenized where the corresponding token is stored within MAO. Throughout the life cycle of each order, MAO uses the card token to process authorizations, settlements, and refunds through integration with the 3rd party payment gateway.
Manhattan Active Omni has pre-built apps with many 3rd party Credit Card Payment Gateways for one or more of the above functionalities which can be leveraged out of the box. Please see each 3rd party vendor to view what functionalities are available.
ADS, or ‘Alliance Data Systems’ is a provider of integrated credit and marketing services including Private Label, co-branded and commercial credit card programs.
Manhattan Active Omni is not integrated with Alliance out of the box. This integration enables communication with Alliance Private Label payment processing by altering the base functionality in the following ways:
An authorization is required to reserve funds to cover the cost of the transaction. This typically occurs during order capture. For Private Label Credit Cards, a call center agent uses the call center screens in MAO to capture the card details. This feature adds the ability for MAO to send the authorization request in the ADS required format via SOAP HTTP web service APIs and update the order based on the response from ADS.
An authorization reversal occurs when a merchant reverses the authorization step of the transaction, before settlement has begun. Manhattan Active Omni (MAO) creates internal authorization reversals when the order total decreases. This feature adds the ability for MAO to externalize the authorization reversal transactions when the full amount on the auth is being reversed in case of an order cancelation. MAO sends the ADS required format via SOAP HTTP web service APIs when an auth reversal is required.
A refund is generated when compensation is owed to a customer. This is typically triggered by a return, uneven exchange, or appeasement. This feature adds the ability for MAO to send the refund request in the ADS required format via SOAP HTTP web service APIs and update the order based on the response from ADS.
Account Lookup provides the CSR an option to lookup a customer’s Private Label Account Number in case the customer cannot is unable to locate their account number. This feature adds the ability for MAO to send an account lookup request based on the customer’s information in the ADS required format via SOAP HTTP web service APIs and update the Account number based on the response from ADS.
A settlement occurs when the authorized funds are actually taken out of the customer’s account. This is typically triggered by a shipment or transfer of goods to the customer. This feature adds the ability for MAO to send a batch end of day settlement file to ADS.
With the end of day settlement performed in batch, this App also includes a UI feature to manually resend End of Day Settlement files from Manhattan Active Omni (MAO) in the event the initial files are lost in transit or incomplete.
Adyen is a global payment company that allows retail businesses to accept e-commerce, mobile, and point-of-sale payments.
For Credit Card payment processing integration, Manhattan Active Omni, MAO for short, integrates with Adyen to process payment transactions. MAO generates the transactions in the format required by Adyen and integrates via Rest APIs.
Additionally, MAO Hosted Checkout capabilities in the call center application are added, which is used to capture and tokenize credit card information via Adyen Gateway from the MAO call center application. During Hosted Checkout, Adyen responds back with the payment token which can then be used for further transactions.
This page details Manhattan Active Omni integration with Adyen Payment Gateway for the following processes:
Payment Types included and supported by Adyen as a part of this App are:
| Payment Type | Pre-Paid? | Refund Type | Void Behavior | Call Center? | Tokenization |
|---|---|---|---|---|---|
| Apple Pay | No | Apple Pay | No | No | Yes |
| Bancontact | Yes | Bancontact | No | No | Yes |
| Credit Card | No | Credit Card | No | Yes | Yes |
| Gift Card | No | Gift Card | No | Yes | Yes |
| iDeal | Yes | iDeal | No | No | Yes |
| Klarna | No | Klarna | No | No | Yes |
| PayPal | No | PayPal | No | No | Yes |
Processes by Payment Type supported by Adyen as a part of this App are:
| Payment Type | Hosted Checkout | Authorization | Authorization Extension | Auth Reversal | Settlement | Refund | Fraud |
|---|---|---|---|---|---|---|---|
| Apple Pay | No | Yes | No | Complete and Partial* | Complete and Partial* | Yes | Yes |
| Bancontact | No | No | No | No | No | Yes | Yes |
| Credit Card | Yes | Yes | Yes* | Complete and Partial* | Complete and Partial* | Yes | Yes |
| Gift Card | Yes | Yes | No | Complete and Partial* | Complete and Partial* | No | Yes |
| iDeal | No | No | No | No | No | Yes | Yes |
| Klarna | No | Yes | No | Complete Only | Complete and Partial | Yes | Yes |
| PayPal | No | Yes | No | Complete and Partial* | Complete and Partial* | Yes | Yes |
* Determined by configuration, processes leveraged can be adjusted to meet customer specific Adyen processing requirements. For example, Credit Cards can be configured to only send Complete Auth Reversals.
Hosted checkout is a Payment Gateway / 3rd party owned screen (iFrame) used to capture payment information during the order creation/modification process in the MAO Call Center. Hosted Checkout makes the payment information capture more secure since the payment information is collected on the payment gateway side and the payment page along with the underlying security is owned by the gateway solution where MAO only invokes the Hosted Checkout page with the necessary order information. Once the payment information is submitted on the hosted checkout page, Adyen sends a token back to MAO, which is stored on the order and can be used for subsequent payment transactions – such as Authorization, Settlement and Refund.
An authorization, or approval from the card issuer through the payment gateway, is required to ensure the customer has sufficient funds to cover the cost of the transaction. MAO creates authorizations in various scenarios such as order capture/modification through the Call Center application or when an authorization is expiring and requires a new authorization. This feature adds the ability for MAO to send an authorization request to Adyen in the required format when an authorization is required.
An authorization of a pre-authorized payment can be adjusted to extend the authorization period. This feature adds the ability for MAO to send an authorization adjustment request to Adyen in the required format when an authorization extension is required.
An authorization reversal may occur when a merchant reverses the authorization step of the transaction for any funds that the merchant does not intend to capture. MAO creates internal authorization reversals when the order total decreases and there are unused funds on the authorization transaction. This feature adds the ability for MAO to externalize the authorization reversal transactions when the remaining amount on the auth is being reversed. MAO sends an authorization reversal request to Adyen in the required format when an auth reversal is required.
A settlement transaction (Capture) is created when product on the order is fulfilled, so issuing bank sends funds to the seller’s payment processor, which disperses said funds to the merchant. This feature adds the ability for MAO to send a settlement request to Adyen in the required format when a payment capture is required.
A refund is required when money is owed to the consumer, triggered by a return, uneven exchange, appeasement, etc. This feature adds the ability for MAO to send a refund request to Adyen in the required format when a refund is required. Usually, a refund is issued for an existing order that is fulfilled and has invoice in Closed status. However, as a part of this App a backend API is included to process a refund without an existing order.
Fraud is processed with Ayden RevenueProtect (RP) to provide capabilities to automate and streamline Order Reviews and Fraud Case Management operations. This feature adds the ability to support fraud check and case resolution between MAO and RP. When an order is updated in RP after being placed on fraud hold, RP provides notifications to MAO on any Fraud Status/Result changes.
Aurus is a leading provider of global payment software and services for retailers.
For Credit Card payment processing integration, Manhattan Active Omni integrates with AurusPay Switch to process payment transactions using Web-Service AESDK version 6.13.8. MAO generates the transactions in the format required by Aurus. Additionally, MAO adds logic for Hosted Checkout in the call center application, which is used to capture credit card information via AurusPay Switch. Then, Aurus returns the payment token, which can then be used for further transactions.
This integration also adds logic to process Gift Card, Klarna, Affirm, PayPal, and Digital Wallet (ApplePay/Google Pay) payment transactions, as well as Safety Pay (Bank Transfers in Mexico) and OXXO payments.
This document details MAO integration with AurusPay Switch via the following transactions:
An authorization, or approval from the card issuer through the payment gateway, is required to ensure the customer has sufficient funds to cover the cost of the transaction. Manhattan Active Omni (MAO) creates authorizations in various scenarios like when an authorization expires and requires a new authorization. This feature adds the ability for MAO to send the Aurus required format when an authorization is required.
An authorization reversal occurs when a merchant reverses the authorization step of the transaction, before settlement has begun. Manhattan Active Omni (MAO) creates internal authorization reversals when the order total decreases. This feature adds the ability for MAO to externalize the authorization reversal transactions when the full remaining amount on the auth is being reversed. MAO sends the Aurus required format when an auth reversal is required.
A settlement transaction is created when product on the order is fulfilled, so issuing bank sends funds to the seller’s payment processor, which disperses said funds to the merchant. This feature adds the ability for MAO to send the Aurus required format when a settlement is required.
A sale is utilized to capture funds when base generates a settlement transaction upon adding a new payment method in the Call Center UI. This feature supports the capture of funds without requiring an authorization transaction.
A refund is required when compensation is owed to a customer; triggered by a return, uneven exchange, appeasement, adjustment invoice etc. This feature adds the ability for MAO to send the Aurus required format when a refund is required.
Hosted checkout, or a 3rd party owned screen (iFrame) used to capture payment information during the order creation process in the Call Center application, is added as part of this feature. Aurus sends a token back to MAO, which is stored on the order and used for subsequent payment transactions.
In scenarios where a timeout occurs when executing a payment transaction with Aurus, a lookup mechanism is required during retry to check if the transaction was processed. This features supports a lookup API call with Aurus before a new transaction is executed. If the transaction that timed out was processed by Aurus, this API returns the response details. Transaction Lookup calls are made for all the transactions listed in this extension except for the Gift Card Balance Inquiry.
For scenarios where a refund must be issued on a gift card as well as scenarios where an E-Gift Card is added to an order as a sellable item, MAO calls Aurus to issue and then activate a new E-Gift Card. The issuance/activation response, which contains the E-Gift Card number and PIN is translated by MAO into a fulfillment order event for the E-Gift Card which generates an outbound message with the E-Gift Card details.
When applying a Gift Card as a payment method in the Call Center application, MAO makes a Balance Inquiry call to Aurus to confirm the card has the funds available. If the available balance is greater than the requested amount, MAO applies the gift card to the order for the requested amount. If the available balance is less than the requested amount, MAO applies the available balance. Additional payment methods are captured to continue the order creation process.
When confirming an MAO Call Center order having a Gift Card applied as payment, MAO sends Aurus a Redeem request for the amount applied on the Gift Card in the Balance Inquiry step. The Gift Card Redeem transaction is modeled as a MAO Settlement transaction, and successful Gift Card redemption results in an order moving to Paid status (if the Gift Card covers the entire order total).
With Pay by Link, customers can input their credit card information using their own mobile device, tablet, or laptop, rather than providing their sensitive credit card information to contact center agents. This reduces the level of risk for customers who are placing orders or making order edits over the phone.
With OXXO payments, customers in Mexico receive a barcode on order confirmation which is saved to their mobile phones. The customer can then has 3 days to show the barcode at an OXXO store and pay for the order, at which point the OXXO payment, through Aurus, is posted to the MAO orders asynchronously. MAO executes payment cancellations for orders fully cancelled prior to payment being posted and refunds for any returns or adustments after payment has been posted.
Chase is the a leading provider of merchant services with over $1 trillion in annual processing volume. Chase Paymentech is a credit card processing solution aimed at larger enterprise businesses.
For Credit Card payment processing integration, Manhattan Active Omni, MAO for short, integrates with Chase Paymentech’s Orbital Gateway to process payment transactions using SOAP Web-Service APIs on version 2.9. MAO generates the transactions in the format required by Chase Paymentech. Additionally, MAO adds logic for Hosted Checkout in the call center application, which is used to capture credit card information via Chase PaymenTech’s Orbital Gateway. Then, Chase returns the payment token, which can then be used for further transactions.
This document details MAO integration with Chase Paymentech Gateway via the following transactions:
An authorization, or approval from the card issuer through the payment gateway, is required to ensure the customer has sufficient funds to cover the cost of the transaction. Manhattan Active Omni (MAO) creates authorizations in various scenarios like when an authorization expires and requires a new authorization. This feature adds the ability for MAO to send the Chase Paymentech required format when an authorization is required.
An authorization reversal occurs when a merchant reverses the authorization step of the transaction, before settlement has begun. Manhattan Active Omni (MAO) creates internal authorization reversals when the order total decreases. This feature adds the ability for MAO to externalize the authorization reversal transactions when the full remaining amount on the auth is being reversed. MAO sends the Chase Paymentech required format when an auth reversal is required.
A settlement transaction is created when product on the order is fulfilled, so issuing bank sends funds to the seller’s payment processor, which disperses said funds to the merchant. This feature adds the ability for MAO to send the Chase Paymentech required format when a settlement is required.
In specific scenarios when the settlement call fails, it may be required to re-authorize the payment transaction in order to settlement. This feature adds the ability for MAO to send the Chase Paymentech required format for scenarios where a failed settlement needs re-processing systematically.
A refund is required when compensation is owed to a customer; triggered by a return, uneven exchange, appeasement, adjustment invoice etc. This feature adds the ability for MAO to send the Chase Paymentech required format when a refund is required.
Hosted checkout, or a 3rd party owned screen (i frame) used to capture payment information during the order creation process in the Call Center application, is added as part of this feature. Chase Paymentech sends a token back to MAO, which is stored on the order and used for subsequent payment transactions.
CyberSource helped kick start the eCommerce revolution in 1994 and has not looked back since. Through global reach, modern capabilities, and commerce insights, CyberSource creates flexible, creative commerce solutions for everyday life—experiences that delight your customers and spur growth globally.
This App adds additional options to the base integration with CyberSource from Manhattan Active Omni Application for the following features:
An authorization reversal occurs when a merchant reverses the authorization step of the transaction, before settlement has begun. Manhattan Active Omni (MAO) creates internal authorization reversals when the order total decreases. This feature adds the ability for MAO to externalize the authorization reversal transactions when the full amount on the auth is being reversed for the credit card. MAO sends the CyberSource required format when an auth reversal is required.
Manhattan Active Omni (MAO) out of box integrates directly with PayPal to process settlement & refund transactions. As part of this feature, MAO integrates with CyberSource Payment Gateway to process PayPal payment transactions via the Alternative Payment PayPal Express using Simple Order API. Manhattan Active Omni sends the request to the CyberSource Payment Gateway, which acts as a middle layer and directly integrates with PayPal. This service captures all payment messages sent from MAO, passes these messages to PayPal, and returns the response to MAO. This includes settlement, refund, and full authorization reversal payment transactions.
Some clients may wish to support alternative payment methods via CyberSource. This feature adds support for Klarna, a Buy Now, Pay Later solution. Manhattan Active Omni sends the request to the CyberSource Payment Gateway using the Alternative Payment Simple Order API, which acts as a middle layer and directly integrates with Klarna. This service captures all payment messages sent from MAO, passes these messages to Klarna, and returns the response to MAO. This includes settlement, refund, reauthorization, and full authorization reversal payment transactions.
Clients may wish to support Bancontact, an e-commerce payment system in Belgium that enables customers to pay for goods using direct bank transfer from their bank accounts directly to your account. MAO integrates with CyberSource Online Bank Transfers using the Simple Order API to process payment transactions. Manhattan Active Omni sends the request to the CyberSource Payment Gateway, which acts as a middle layer and directly integrates with Bancontact. This service captures all payment messages sent from MAO, passes these messages to Bancontact, and returns the response to MAO. This includes follow-on refund transactions against Bancontact payment method settlements.
Clients may wish to support iDEAL, an e-commerce payment system in the Netherlands that enables customers to pay for goods using online bank transfers from their bank accounts directly to your account. MAO integrates with CyberSource Online Bank Transfers using the Simple Order API to process payment transactions. Manhattan Active Omni sends the request to the CyberSource Payment Gateway, which acts as a middle layer and directly integrates with iDEAL. This service captures all payment messages sent from MAO, passes these messages to iDEAL, and returns the response to MAO. This includes follow-on refund transactions against iDEAL payment method settlements.
Clients may wish to support Przelewy24, an e-commerce payment system in Poland that enables customers to pay for goods using direct online bank transfers from their bank accounts directly to your account. MAO integrates with CyberSource Online Bank Transfers using the Simple Order API to process payment transactions. Manhattan Active Omni sends the request to the CyberSource Payment Gateway, which acts as a middle layer and directly integrates with Przelewy24. This service captures all payment messages sent from MAO, passes these messages to Przelewy24, and returns the response to MAO. This includes follow-on refund transactions against Przelewy24 payment method settlements.
CardConnect is a payments platform of Fiserv, focused on helping businesses of all sizes grow through the seamless integration of secure payment processing.
This integration enables communication for Manhattan Active Omni (MAO) Point of Sale (POS) card payment flows with Fiserv’s CardConnect platform (API version V3). Card payment types supported through this integration include Credit Cards and Debit Cards.
Integration between MAO POS and Fiserv’s CardConnect Platform is implemented using REST Web-Service APIs. Card-present payment transactions are integrated from the POS register application in the store to CardConnect’s BOLT REST APIs while Card-not-present payment transactions are integrated from the MAO Cloud Server to CardConnect’s CardPointe REST APIs.
MAO sends requests to Fiserv CardConnect in the format required by Fiserv and processes responses from Fiserv back into MAO.
This document details MAO integration with Fiserv CardConnect Gateway via the following transactions:
The Bolt API Connect initiates a session between POS register and the Payment Terminal (terminal). The session key returned by the Connect API is required to be included in all subsequent API requests to the Bolt webservice. MA POS initiates the session when a transaction is created in POS and closes the session once the transaction is completed, voided or suspended. The Bolt API Disconnect is executed to close the session between the register and terminal.
The Bolt API Display is executed by POS to display the latest updates to the shopping cart on the payment terminal. Each time the cart is modified, such as by adding an item or overriding a price, the POS register calls the display API to update the payment terminal screen with the details of the current state of the cart.
This applies only to Fixed POS Registers where the customer typically cannot see the cart on the POS register UI. In case of Mobile POS Registers, cart is not displayed on the terminal since the user can easily share the POS UI with the customer.
POS executes the authCard Bolt API with the Capture flag set to true to capture payment for a cash and carry transaction. This causes CardConnect to prompt for card entry (among other things) and Authorize and Capture the payment as part of a single API call.
Capture is the process of queuing a payment transaction for Settlement. Settlements are run overnight by Fiserv CardConnect at a pre-configured time agreed to with merchant. Settlement triggers the issuing bank to transfer funds to the merchant’s bank (Acquirer).
A Void operation reverses a payment transaction such as a capture or refund before settlement has occurred. MAO POS executes void in a few different scenarios:
Refunds are executed in MAO POS to process returns or negative exchanges. Depending on the type of return different types of refunds are executed:
SAF is a mechanism by which a payment can be captured with card present on the payment terminal even while the payment terminal is unable to connect to the gateway (Bolt Service). In such a scenario the payment capture is stored locally on the payment terminal until such time the payment terminal’s connection to the Bolt Service is restored. Then the payment terminal uploads all the captured payments (and refunds) to the gateway.
When capturing or editing a customer address on POS fixed register, this feature allows MAO to display the address on the payment terminal for confirmation by customer before it is saved. It allows the customer to specify if the displayed address is correct or not.
Manhattan Active Omni solutions maintain a customer entity used for storing customer information needed to track purchases and interactions with the brand. The customer entity stores:
Manhattan Active Omni has pre-built apps with many 3rd party Customer Relationship Management providers which can be leveraged to retrieve and update customer information needed within MAO out of the box. Please see each 3rd party vendor to view what functionalities are available.
Salesforce Commerce Cloud is an ecommerce web platform.
Manhattan Active Omni is not integrated with Salesforce out of the box. This integration enables communication with Salesforce by altering the base functionality in the following ways:
These services are invoked when a new customer is created via the MAO Point of Sale or Customer Service modules.
This service to SFCC is invoked in POS or Customer Service modules when the user is searching for an existing customer and returns a list of customers for the user to choose from and eventually apply the customer to the order.
This service to SFCC is invoked when in POS or Customer Service modules when a new customer is created and returns a customer ID, which is saved on the customer record.
Manhattan Active Omni solutions provide clients with a framework to integrate with 3rd party fraud detection services to hold orders which are flagged as fraudulent, ensuring they are not released for fulfillment until a fraud review is performed. If an order has been put on hold due to potential fraud, then a fraud analyst can analyze the situation and take steps to resolve the alert.
Manhattan Active Omni has pre-built apps with many 3rd party fraud providers which can be leveraged out of the box. Please see each 3rd party vendor to view what functionalities are available.
Adyen is a global payment company that allows retail businesses to accept e-commerce, mobile, and point-of-sale payments.
This page details Manhattan Active Omni integration with Adyen Payment Gateway for the following processes:
Processes by Payment Type supported by Adyen as a part of this App are as follows:
| Payment Type | Fraud |
|---|---|
| Apple Pay | Yes |
| Bancontact | Yes |
| Credit Card | Yes |
| Gift Card | Yes |
| iDeal | Yes |
| Klarna | Yes |
| PayPal | Yes |
Fraud is processed with Ayden RevenueProtect (RP) to provide capabilities to automate and streamline Order Reviews and Fraud Case Management operations. This feature adds the ability to support fraud check and case resolution between MAO and RP. When an order is updated in RP after being placed on fraud hold, RP provides notifications to MAO on any Fraud Status/Result changes.
ClearSale is a fraud management and chargeback protection services company.
Manhattan Active Omni is not integrated with ClearSale out of the box. This integration enables communication with ClearSale by altering the base functionality in the following ways:
For the defined order types MAO makes a call to ClearSale for fraud check before the order is released. ClearSale responds with a fraud decision - accept, failure, or review. For accept, the fraud hold is removed and the order is eligible for release. For failure, MAO cancels the order, and for review, the order is updated with a fraud review hold that requires a manual fraud review.
If no response is received from the fraud call to ClearSale, MAO has a retry scheduler to retry the fraud call on a configurable schedule.
If a manual fraud review is required, ClearSale sends an asynchronous message when the fraud analysts makes a final decision. MAO processes the message and updates the order with the fraud details according to the fraud response - accept or failure. The asynchronous message must be translated to the format defined as part of this integration.
In an exception scenario where ClearSale is unavailable for an extended period, a fraud analyst may remove a fraud hold in MAO directly given that the user has the newly added permission. Without this permission, the user is prevented from editing orders on a fraud hold or removing the fraud specific holds from the order.
CyberSource’s Decision Manager is a fraud protection platform, which features a flexible rules engine. Decision Manager allows customers to screen orders for risk to help prevent fraud.
This integration extends the base-supported authorization integration with CyberSource by utilizing three methods:
The Decision Manger API allows for integration between Manhattan Active Omni and CyberSource’s Decision Manager. The integration with Decision Manager (DM) provides the client capabilities to automate and streamline Order Reviews and Fraud Management operations.
For orders placed in the MAO Customer Servic emodule, a call to CyberSource for authorization is made with the additional fields added for CyberSource to perform the fraud check before the order is released. CyberSource responds with a fraud decision - accept, failure, or review. For accept, the fraud hold is removedand the order is eligible for release. For failure, MAO cancels the order, and for review, the order is updated with a fraud review hold that requires a manual fraud review.
MAO periodically checks the fraud status of any order that is in Fraud Review with CyberSource DM. This task utilizesthe DM API to check the status of the order and allows MAO to process any updates based on manual review of the order.
For order edits where no new authorization is required, MAO sends a standalone fraud call to CyberSource DM and updates the order based on the fraud response.
Signifyd is a software as a service fraud and chargeback prevention technology. Signifyd’s technology helps detect and prevent fraud.
Manhattan Active Omni is not integrated with Signifyd out of the box. This integration enables communication with Signifyd by altering the base functionality in the following ways:
For the defined order types MAO makes a call to Signifyd for fraud check before the order is released. Signifyd responds with a fraud decision – accept, failure, or review. For accept, the fraud hold is removed and the order is eligible for release. For failure, MAO cancels the order, and for review, the order is updated with a fraud review hold that requires a manual fraud review.
If no response is received from the fraud call to Signifyd, MAO has a retry scheduler to retry the fraud call on a configurable schedule.
If a manual fraud review is required, Signifyd sends an asynchronous message when the fraud analysts makes a final decision. MAO processes the message and updates the order with the fraud details according to the fraud response – accept or failure. The asynchronous message must be translated to the format defined as part of this integration.
In an exception scenario where Signifyd is unavailable for an extended period, a fraud analyst may remove a fraud hold in MAO directly given that the user has the newly added permission. Without this permission, the user is prevented from editing orders on a fraud hold or removing the fraud specific holds from the order.
Manhattan Active Omni solutions provide clients the ability to sell or to transact with gift cards.
Physical or electronic gift cards may be purchased through the website, Contact Center, or POS, which leverages integration with the external gift card provider to activate the gift card.
Gift card as a tender is supported with integration to the external gift card provider to process the payment. This includes:
Manhattan Active Omni Point of Sale provides additional capabilities for store users to perform balance inquiries, reload or activate a gift card, and cash out remaining balance under a defined threshold.
Manhattan Active Omni has pre-built apps with many 3rd party gift card providers which can be leveraged out of the box for one or more of the above functionalities. Please see each 3rd party vendor to view what functionalities are available.
Clutch is an innovative data-centric marketing solution platform empowering brands with the best technology so that they can identify, understand, and motivate their customers. Clutch provides traditional marketing CRM, loyalty, gift card, mobile, email, and direct mail solutions individually or as part of a unified platform.
This Clutch integration enables Manhattan Active to support the following features:
When a CSR adds a gift card to an order in the Call Center UI, Manhattan Active Omni generates a payment transaction to determine the available funds on the card. MAO makes a synchronous call to Clutch and sends only one message per gift card. If the available balance is greater than the requested amount, Manhattan Active Omni applies the gift card to the order for the requested amount. If the available balance is less than the requested amount, Manhattan Active Omni applies the available balance. Additional payment methods are captured to continue the order creation process.
In the Call Center UI, when a CSR places an order requiring a gift card tender authorization, MAO sends an authorization/hold transaction to place a hold on the funds to Clutch. If the approved amount is less than the requested amount, then MAO accepts the response to make the appropriate updates. The correct available, applied, and remaining amounts are displayed in the payment tab of the Call Center UI.
A settlement request to Clutch is sent to redeem gift card payment transactions. When an order is shipped, an invoice is generated to mark the sale of goods. If an order is fully shipped, MAO uses the invoice to generate a settlement transaction. If the order is partially shipped, a scheduled job is configured to batch process any open settlement transactions, generating individual calls for each open transaction to Clutch. The redeem transaction releases the remaining funds from the related hold transaction. If all order lines are not shipped, Manhattan Active Omni generates an advanced hold transaction upon a successful response. The advanced hold record is used for any subsequent settlement transactions, until a new hold is generated, or the order is fully shipped or canceled.
Manhattan Active Omni uses the authorization reversal interface when an authorization reversal transaction is generated for a gift card authorization. The message interfaced to Clutch is like the settlement request, however, the requested amount is always $0. MAO closes the authorization record and releases the funds for the related hold in Clutch.
When a customer purchases a Gift Card both Electronic / Physical, there are a series of steps involved in fulfilling and activating the Gift Card for the customer to Use. Manhattan Active Omni orchestrates the fulfillment of both the Physical and Electronic Cards and handles the activation of the same.
When a Gift Card order is Released to Fulfillment based on the type of Gift Card the following steps are performed
Only applicable for Electronic Gift Card, when an Electronic Gift Card is released MAO makes an Allocate call to Clutch using the CardsetID, which returns the Gift Card Number and optional PIN.
A Gift Card Activation request to Clutch is generated when the fulfillment center ships the physical gift card. For electronic gift card, the call is generated after a successful Allocate call. This message includes the Gift Card Number and Pin, if available.
For both types of gift cards, once the gift card is activated, a Gift Card Issuance request to Clutch is generated to issue the value to the card . MAO makes a synchronous call to Clutch and sends one message per gift card. If multiple gift card issuances are required, multiple messages are sent.
Eigen is a payment management service that can be used for Gift Card issuing and management.
This Eigen integration enables Manhattan Active to support the following features:
After customers make purchases using a gift card, they generally discard the gift card. Therefore, when a refund or appeasement is processed for the customer, the funds are not put back on the original gift card. If the payment method on the original order is a gift card and a refund transaction is created, a new electronic gift card is issued. In addition, new gift cards are issued as a refund tender when gift recipients return items. For example, if a customer purchases an item as a gift and pays using a credit card, and the gift recipient returns the item, the refund is also issued as a new gift card.
When the call to Eigen to activate and issue a new E-Gift Card fails with an unavailable response, MAO retries the call to Eigen on a configurable schedule up to the max retry attempts.
Givex offers gift card, loyalty and stored value ticketing solutions which drive sales for clients, help them better understand, reward and entice their customers and ultimately make better-informed business decisions.
This integration enables integration to Givex for two Payment Methods:
In the context of this integration a Store Card is essentially a Gift Card except it must be redeemed within the store only and not through other channels. This is managed in Givex by assigning a Gift Card to a Group. By the virtue of the card being associated to the group it is limited to be redeemed only from stores. The details of the mechanisms / configurations by which this is accomplished is outside the scope of this document and is managed between the Retailer and Givex.
The features within this integration explained more below include: • Card Entry • Redemption • Cash Out • Refund • Balance Inquiry • Activation • Reload • Exchange Tender
This feature provides the ability for the customer to barcode scan a Gift Card or Store Card into the Manhattan Active Omni POS UI. This feature requires integration with a barcode scanner to be implemented outside the scope of this integration.
Redeeming is the process of using a Gift Card or Store Card to pay for a purchase in the Manhattan Active Omni POS Application. Funds equal to the redemption amount is reduced from the available funds on the card following a successful redemption.
Immediately following a redemption, if the balance remaining on the card (GC or SC) is below a threshold value (configured in MAO) then customer has the option to cash out the remaining balance in Manhattan Active Omni POS Application. This function is used to redeem (Forced Cashback Redemption) the remaining amount on the Gift Card or Store Card.
Refund results from processing a return or a negative exchange where customer is issued funds to an existing or new card (Gift Card or Store Card).
Balance Inquiry is a function in the Manhattan Active Omni POS Application that allows the user to query the balance of an existing Gift Card or Store Card.
Activation is the process of adding funds to a new gift card and making it available to be redeemed. In the Manhattan Active Omni POS application activation is performed once the balance due becomes zero, for an order that contains a Gift Card line item. Note activation is supported only for Gift Cards and not for Store Cards since Store Cards are not sold as line items.
Reloading is the process of adding funds to an existing card (an activated card that the customer already owns). This process does not require activation since the card is already activated, it simply adds more funds to the card.
This function is utilized to return cash to a customer for a Gift Card or Store Card that they own. Alternately this function may also be utilized if a customer has multiple Gift Cards (or Store Cards) and wants to consolidate the funds in those cards to a single card
SmartClixx is a gift card provider and payment gateway used to issue, charge against, check balances, and other miscellaneous gift card transactions.
This SmartClixx integration enables Manhattan Active to support the following features:
When physical gift cards are added to the order, they are fulfilled by a fulfillment center who scans the card during picking to add the serial number (card number) to the order. This information is passed back to Active Omni on the Order Event (ship confirmation) message. An interface is used to relay the Gift Card Activation request to SmartClixx in the required format. The MAO generates the activation call, consumes the response, and passes the order event message along to mark the physical gift card as shipped.
When electronic gift cards are added to the order, they are fulfilled virtually through integration with SmartClixx. Active Omni sends a request to SmartClixx to retrieve a card number and CVV2 value from SmartClixx. This information is passed back to Active Omni in the response and used to generate the next call, Activate, to load value to the card. Once the response is received back, the App forms an Order Event message that completes the lifecycle of the order line(s) with the card number and CVV2 value included.
When parts of the order ship, Active Omni reaches out to SmartClixx to inform them that the gift card has less funds available. Each shipment that occurs results in an individual settlement (capture) transaction reaching out to SmartClixx, further reducing the available funds remaining on the gift card.
When an order is canceled or partially canceled, SmartClixx expects an authorization reversal transaction initiated from Active Omni to release the funds. Active Omni calls SmartClixx on a scheduled basis to perform authorization reversal to remove the hold on the gift card funds.
SVS (Stored Value Solutions) is a global provider of gift card and stored value services.
This SVS integration enables Manhattan Active to support the following features: • Balance Check • Pre-Authorization (Authorization) • Pre-Authorization Complete (Settlement) • Pre-Authorization Complete $0 (Authorization Reversal) • Issue Virtual Gift Card • Activate Physical Gift Card
When a CSR adds a gift card to an order in the Call Center UI, Manhattan Active Omni generates a payment transaction to determine the available funds on the card. MAO makes a synchronous call to SVS and sends only one message per gift card. If the available balance is greater than the requested amount, Manhattan Active Omni applies the gift card to the order for the requested amount. If the available balance is less than the requested amount, Manhattan Active Omni applies the available balance. Additional payment methods are captured to continue the order creation process.
In the Call Center UI, when a CSR places an order requiring a gift card tender authorization, MAO sends an authorization/hold transaction to place a hold on the funds to SVS. If the approved amount is less than the requested amount, then MAO accepts the response to make the appropriate updates. The correct available, applied, and remaining amounts are displayed in the payment tab of the Call Center UI.
A Pre-Authorization Complete (settlement) request to SVS is sent to redeem gift card payment transactions. When an order is shipped, an invoice is generated to mark the sale of goods. If an order is fully shipped, MAO uses the invoice to generate a settlement transaction. If the order is partially shipped, a scheduled job is configured to batch process any open settlement transactions, generating individual calls for each open transaction to SVS. The Pre-Authorization Complete transaction releases the remaining funds from the related hold transaction. If all order lines are not shipped, Manhattan Active Omni generates an advanced hold transaction upon a successful response. The advanced hold record is used for any subsequent settlement transactions, until a new hold is generated, or the order is fully shipped or canceled.
Manhattan Active Omni uses the authorization reversal interface when an authorization reversal transaction is generated for a gift card authorization. The message interfaced to SVS is like the settlement request, however, the requested amount is always $0. MAO closes the authorization record and releases the funds for the related hold in SVS.
MAO issues a new Electronic Gift Card for many refund scenarios. MAO utilizes the release of the Electronic Gift Card item to trigger the custom activation calls for Electronic Gift Card. This synchronous call to SVS receives either a successful, failure, or unavailable response from SVS. MAO updates orders to shipped for successful scenarios. MAO also handles scenarios in which SVS is unavailable and resends the request based on the number of retries available.
MAO activates a Physical Gift Card upon receiving the ship event from the fulfillment center. MAO utilizes the Gift Card Number and optional PIN on the ship event to send the custom activation call for Physical Gift Cards. This synchronous call to SVS receives either a successful, failure, or unavailable response from SVS. MAO updates orders to shipped for successful scenarios. MAO also handles scenarios in which SVS is unavailable and resends the request based on the number of retries available.
First Data, now Fiserv, is a global leader in payments and financial technology, where ValueLink is their proprietary gift card solution.
This ValueLink integration enables Manhattan Active to support the following features:
When physical gift cards are added to the order, they are fulfilled by a fulfillment center who scans the card during picking to add the serial number (card number) to the order. This information is passed back to Active Omni on the Order Event (ship confirmation) message.
An interface is used to relay the Gift Card Activation request to ValueLink in the required format. The MAO generates the activation call, consumes the response, and passes the order event message along to mark the physical gift card as shipped.
When electronic gift cards are added to the order, they are fulfilled virtually through integration with ValueLink. MAO sends a Gift Card Activation request to ValueLink in the required format, consumes the response, and passes the order event message along to mark the electronic gift card as shipped.
When a CSR adds a gift card to an order in the Call Center UI, Manhattan Active Omni generates a payment transaction to determine the available funds on the card. MAO makes a synchronous call and sends only one message per gift card. If the available balance is greater than the requested amount, Manhattan Active Omni applies the gift card to the order for the requested amount. If the available balance is less than the requested amount, Manhattan Active Omni applies the available balance. Additional payment methods are captured to continue the order creation process.
When the order is shipped or partially shipped, the MAO reaches out to ValueLink to inform them that the gift card has less funds available. Each shipment that occurs results in an individual settlement (capture) transaction reaching out to ValueLink, further reducing the available funds remaining on the gift card.
Voucher Express is an industry-leading e-commerce solution that manages the online sale of gift vouchers, gift cards, and electronic gift cards.
This Voucher Express integration enables Manhattan Active to support the following features:
After customers make purchases using a gift card, they generally discard the gift card. Therefore, when a refund or appeasement is processed for the customer, the funds are not put back on the original gift card. If the payment method on the original order is a gift card and a refund transaction is created, a new electronic gift card is issued. In addition, new gift cards are issued as a refund tender when gift recipients return items. For example, if a customer purchases an item as a gift and pays using a credit card, and the gift recipient returns the item, the refund is also issued as a new gift card.
Worldpay is the world’s largest processor and payments advocate and provides services to merchants and financial institutions in the US.
Worldpay provides tools to simplify payment strategies including credit cards, ATM processing, and merchant services as part of a unified platform.
This feature adds integration with Worldpay for Gift Card processing including the following capabilities:
As part of this feature, MAO integrates with Worldpay to send Gift Card Reload Transactions via the Native RAFT API. Manhattan Active Omni sends data to Worldpay Payment Component that is required to generate request to load funds onto Physical Gift Cards. This service captures Order Event data from MAO for pGC shipments and generates and transmits request to Worldpay and returns the response to MAO.
Manhattan Active Omni solution provides clients the ability to maintain customer loyalty information used for various reward incentives. Many clients integrate with a 3rd party loyalty system to manage tracking loyalty points based on purchases, as well as the ability to redeem earned rewards on future orders.
Manhattan Active Omni has pre-built apps with many 3rd party loyalty systems which can be leveraged out of the box. Please see each 3rd party vendor to view what functionalities are available.
500friends is a loyalty marketing platform that helps you retain, engage, understand, and connect to your customers. 500Friends integrates seamlessly with host systems to handle all customer loyalty metrics such as how many loyalty points a customer has earned per transaction committed & how much remaining value is available on a customer’s loyalty certificate.
Manhattan Active Omni is not integrated with 500Friends out of the box. This integration enables communication with 500Friends by altering the base functionality in the following ways:
There is a Custom SOAP API to 500 Friends to validate certificate Ids upon loyalty certificates being used as a payment method on the order. Request Parameters include Certificate Id and Amount of Certificate. Response Parameters include the status and actual amount of the certificate. MAO makes this call when a user enters a loyalty certificate as a payment method on the call center UI. Whenever a Loyalty Certificate is applied, a tax call must be made to recalculate taxes. The Loyalty Certificate amount is prorated by weight across all items while making the tax call. This is a temporary proration and is not saved after the tax call is made.
Manhattan Active Omni performs a synchronous Balance Check transaction call when a Loyalty Certificate tender is added to an order. When adding a Loyalty Certificate tender to an order, a CSR will capture a card number and pin and enter those into the payment details in the Call Center UI. Active Omni then generates a Balance Check transaction in the 500Friends format when a CSR presses “Add” to confirm the addition of the Loyalty Certificate tender.
Manhattan Active Omni performs an Authorization transaction call for a Loyalty Certificate tender when either an order is placed or updated in the Call Center UI, which contains a Loyalty Certificate tender that has yet to be authorized. MAO also performs an Authorization call if an order is sent with a valid Loyalty Certificate number without an authorization transaction record. If an order or portion of the order is canceled where an Authorization Reversal transaction is generated, MAO sends a call in the 500Friends format to mark the payment as no longer valid. Dummy Settlement and Refund transactions are generated for Loyalty Certificates and are closed by MAO with no calls to 500Friends.
Manhattan Active Omni solutions provide clients the ability to integrate with external parcel carriers for label generation and package tracking visibility. Use cases include:
Manhattan Active Omni has pre-built apps with many 3rd party Parcel Carriers for one or more of the above functionalities, which can be leveraged out of the box. Please see each 3rd party vendor to view what functionalities are available.
Blue Express provides door-to-door service to distribute products to more than 300 cities throughout Chile in an agile and safe way. The Blue Express shipping network provides national and international distribution, retail distribution, home delivery and commercial deliveries.
This integration adds functionality for Manhattan Active Omni to call Blue Express Tracking Pull web service, specifically the obtainDocument Service Method (Método obtenerDocumento). This provides the capacbility to track shipments within Manhattan Active Omni Digital Self Service (DSS) when a customer tracks a package associated to a Blue Express service order (OS).
Retailers may provide the ability to track shipments via MAO DSS. To access the Shipment Tracking UI, a customer can use the “Track Package” link provided in the shipment confirmation email/text or via the link provided in an e-commerce site. One Shipment Tracking page is displayed per package.
The Digital Self-Service Shipment Tracking page displays details about a package, including:
Self-Service makes a real time API call to the carrier such as FedEx to retrieve the latest package status. Out of the box integration exists for FedEx, UPS, and USPS.
This feature provides additional integration for 3rd party carrier, Blue Express. When a user accesses the Shipment Tracking UI for a package shipped via Blue Express, a real time call is made to the Blue Express obtainDocument web service to retrieve the latest status of the package as well as the tracking history using the Blue Express service order (OS) as tracking number.
Canada Post is a carrier that acts as the primary postal operator in Canada.
Manhattan Active Omni is not integrated with Canada Post out of the box. This integration enables communication with Canada Post by altering the base functionality in the following ways:
When a user initiates a return in Manhattan’s Contact Center the customer needs a return shipping label to ship their items to the return center. When a return order with receipt expected is initiated and confirmed in EOM, a call is made to the carrier to create and retrieve a return shipping label as well as generate a tracking number. Upon a successful response from Canada Post, the return label is stored within the EOM Document Component, and the return tracking number is saved against the order. Each return label contains the customer’s address, return center address, return order id and return tracking number. Canada Post requires that two calls be made to obtain a return tracking number: Create Authorized Return and Get Artifact.
When a user completes a package in Manhattan’s Store Fulfillment module, a ship request is generated, which communicates the service level, ship from and ship to address and other relevant package information. This ship request is generated to the required format for the two calls to Canada Post to get the tracking number and shipping label. The Canada Post response is translated back to the Store Fulfillment format where the tracking number is saved against the package, and the 4 X 6 PNG shipping label is saved in the document repository to be printed with the pack slip.
Additionally, based on configuration, a return label will be generated to be sent to the customer along with the shipping label. This will be two separate calls to Canada Post that will happen simultaneously to the calls made for the shipping label if configured to do so. The Canada Post response is translated back to the Store Fulfillment format where the return tracking number is saved against the package and the 4 X 6 PNG return label is saved inn the document repository to be printed with the pack slip.
Once a package is built and has a tracking number for the Create Shipment response, a batch job scheduler runs periodically and pings Canada Post with this information. The frequency of this scheduler is configurable as a cron expression. The status code from the Canada Post Get Tracking response is mapped back to the payload. If the status code indicates possession from the carrier, it is configured with the status “InTransit” and the OMNI Fulfillment API updates the package to “Shipped” status. If any packages have not updated to an in-transit status, the package status remains in “Built”. Any packages that remain in “Built” status should be included in the subsequent requests triggered by the job scheduler.
Store associates might need to print a new label for a package that was already prepared in store. In that case, they can use the ‘Reprint’ menu in the store application where they have the option to either reprint the label that was already printed or to update the Carrier details before submitting a new call to Canada Post to generate a new label. In the event where they decide to update the Carrier details and print a new label, a Void Shipment call is made to Canada Post to void the previous label.
Channel Advisor is a provider of cloud-based solutions to e-commerce companies. Channel Advisor helps global brands and retailers solve their marketplaces, digital marketing, direct-to-consumer, first-party retail, drop ship and fulfillment needs — all in a single, centralized platform.
Manhattan Active Omni is not integrated with Channel Advisor out of the box. This integration enables communication with Channel Advisor by altering the base functionality in the following ways:
During fulfillment from the SOF (Store Order Fulfillment) system, the Manhattan Active Omni system evaluates the carrier required for fulfillment. After a package has been created and closed, a call is made to a carrier to receive the appropriate tracking information and label. This integration allows for carrier configuration to determine when Channel Advisor calls should be executed versus other carriers (such as FedEx, UPS, etc.).
Chilexpress is the leading Chilean private company in the courier market and in express shipping services. Chilexpress provides clients with express distribution services, logistics transport and international trade, as well as money transfers, collections and electronic commerce.
Manhattan Active Omni is not integrated with Chilexpress out of the box. This integration enables communication with Chilexpress using the REST Transport APIs by altering the base functionality in the following ways:
Retailers may provide the ability to track shipments via MAO DSS. To access the Shipment Tracking UI, a customer can use the “Track Package” link provided in the shipment confirmation email/text or via the link provided in an e-commerce site. The Digital Self-Service Shipment Tracking page displays details about a package, including:
Self-Service makes a real time API call to the carrier to retrieve the latest package status. Out of the box integration exists for FedEx, UPS, and USPS. This feature provides additional integration for 3rd party carrier, Chilexpress. When a user accesses the Shipment Tracking UI for a package shipped via Chilexpress, a real time call is made to the Chilexpress Individual Shipping Consultation API to retrieve the latest status of the package as well as the tracking history.
Retailers may provide the ability to create returns and same-style exchanges via DSS. Customers can initiate the self-service exchange flow in a few different ways. One is via the link provided in the shipment confirmation email. Another is if the retailer provides a link to return in the customer’s My Account page in e-commerce. A third way to initiate the flow is if the retailer offers a link in e-commerce to initiate returns, even for customers who are not logged in.
Customers can select items to return or exchange, quantity to return, and reason for return. After confirming the return, the customer is emailed a return label. The customer can also download a copy of the return shipping label and use it to ship the return items back. Customers can view and print the return label by using built-in browser functionalities to save or print the return label. In case the return label cannot be created or retrieved, an appropriate error message is displayed to the customer so that they can reach out to the contact center for help.
Base Return label generation is supported for FedEx, UPS, and USPS (the same carriers which are supported in customer service). This feature enables DSS Self-Service returns using Chilexpress as Return Carrier. If the Return Shipping Method is tied to a Chilexpress Carrier Service, upon confirming the DSS return, the Chilexpress App is invoked to generate a return label using the Generate Shipment API.
Expert in e-commerce logistics and transport management for individuals (BtoC) and professionals (BtoB), CrossLog International offers its customers a scalable offer for their e-shop. As a WMS and TMS software editor, CrossLog International provides its customers all the necessary tools to drive their business and communicate dynamically with their consumers.
Manhattan Active Omni “MAO” is not integrated with Crosslog out of the box. This integration enables communication Crosslog by altering the base functionality in the following ways:
When a user completes a package in Store Inventory & Fulfillment “SI&F”, a ship process is initiated in MAO, which communicates the relevant data to Crosslog to get the shipping and return tracking numbers and labels. Crosslog requires a Customer Order to be created in their database before any ship or return request can be done. The customer order creation, CreatePacks and GetParcelReturn are translated to the Crosslog required format with the expected data for Crosslog to generate those labels. The Crosslog response is translated back to Store Fulfillment format where the tracking numbers are saved against the package, and the PDF labels are saved in the Supply Chain Document Management API to be printed with the packing slip.
In the same sequence as the labels printing, MAO also communicates with Crosslog to get the Crosslog edited Packing Slip. This Packing Slip is added to the collate and printed within the same PDF file via a popup on the app. All the documents are stored separately in MAO but merged together in one document to be printed by the store associate.
Once the labels are printed in store, the orders are Packed in MAO. Later in that day the carrier comes to collect the Packed orders and scans them to ensure the transfer of ownership is properly done. The carrier then updates Crosslog’s order status to a specific code that marks the order as in transit to the end customer.
MAO runs a scheduled job to get the order state of all Packed orders and moves those orders to Shipped when Crosslog returns this specific code.
Cycleon is an industry-leading, international returns management solution which integrates seamlessly with host systems to handle return label generation for multiple carriers.
Manhattan Active Omni is not integrated with Cycleon out of the box. This integration enables communication with Cycleon using ILS Core version 6.05 by altering the base functionality in the following ways:
When a package is created in SI&F (Store Inventory & Fulfillment), and the user finishes packing a package, MAO calls Cycleon who returns the return label in the format configured within MAO for the corresponding store. The return label size is the standard 4” X 6” or 4” X 4” labels provided by the carriers. SI&F does not resize the label. Although, the return label size is configurable via the custom Configstore API.
EOM will send a return label message for each package that is to be processed. If successful, the response nodes are returned and the Cycleon Id is persisted to the fulfillment detail; otherwise an ERROR node will be returned with a human-readable message.
The language on the label is determined by the address from where the label is mailed.
The reprint option is also available per base Manhattan Active Omni in case the label is damaged or unsuccessfully printed in any way. If the label has previously been printed, it is persisted in the Document Management Server and MAO can pull the previously generated label. If the label has failed to generate, a new request is sent to Cycleon.
DHL is an industry-leading carrier shipping solution that integrates seamlessly with host systems to handle all small parcel, LTL and TL return orders.
Out of the box, Manhattan Active Omni Store Fulfillment does not integrate with DHL. This integration enables communication with DHL by altering the base functionality in the following ways:
This feature adds integration with DHL to track the delivery status and to make a call to DHL Rate and Shipment service to initiate a Return. DHL receives the request and responds with the Return Tracking Number and Return Label. Return Label is saved as a PDF file in the Document API of Manhattan Active Omni. This document covers two returns processes:
FedEx Corp. provides customers and businesses worldwide with a broad portfolio of transportation, e-commerce and business services. FedEx Express and FedEx Express are the business segments that provide parcel shipping services.
This integration extends the base-supported Store Fulfillment integration with FedEx by adding the following:
Retailers may schedule reoccurring Pickups if their Store Locations are eligible for the service. Other businesses may require On-Call Pickup Requests if they are not eligible for scheduled Pickup.
The Pickup Service WSDL allows you to schedule a courier to pick up a shipment, cancel a pickup request, or check for pickup availability. As part of this feature, the Pickup Service is used to check for pickup availability and schedule courier pickup of a shipment at the location specified in the transaction.
When a Store has at least one Package manifested with FedEx Express Service Level, a PickupAvailabilityRequest is made to determine whether Pickup Service is available that day at the given Store Location. Based on the PickupAvailabilityReply, a CreatePickupRequest call is made.
Logistyx TME is a SaaS-based Transportation Management Solution for global parcel shipping that guarantees carrier compliance, streamlines transportation booking, monitors parcel delivery movements, and identifies ongoing opportunities to increase profits per shipment.
This integration enables communication with Logistyx by altering the base functionality in the following ways:
When a user completes a package in Store Fulfillment, a ship request is generated, which communicates the ship from, ship to address and other relevant package information. This ship request is translated to the Logistyx required format with the expected data for Logistyx to select the carrier and generate the shipping label. The Logistyx response is translated back to the Store Fulfillment format where the tracking number is saved against the package, and the 4 X 6 PNG shipping label is saved in the document repository to be printed with the pack slip.
Rate Shopping allows Logistyx to compare carriers and service levels that meet the expected commitment date and ultimately choose the lowest-cost method to ship a package. There is a rate group assigned to each service level, where the corresponding Logistyx Rate Group Name and Id are configured in MAO. The rate group information is sent in the request to Logistyx for each package.
MetaPack is a leading provider of eCommerce delivery management technology to enterprise retailers and brands. The MetaPack platform integrates over 470 carriers and 5,500 delivery services to ensure that retailers and brands can offer delivery options and convenience for their customers.
Manhattan Active Omni is not integrated with Metapack out of the box. This integration enables communication with MetaPack Manager 5.x from Manhattan Active Omni “MAO” and Manhattan Active Warehouse Management “MAWM” for:
Rate Shopping allows MetaPack to compare carriers and service levels that meet the expected commitment date and ultimately choose the lowest-cost method to ship the package or order based on the business rules set up in MetaPack. If enabled - a rateshop group is sent to MetaPack that corresponds to a Service Group on the MetaPack Side, which allows MetaPack to perform rate shopping amongst similar shipping methods.
When a user completes a package, a ship request is generated that communicates the service level, ship from, ship to address and other relevant package information to MetaPack. The base ship request from the Parcel API is updated to allow integration with MetaPack. A shipment call is sent in MetaPack’s required format, where MetaPack creates the consignment for visibility to the carrier’s open manifest, and a shipping label is returned from this call.
After the packing process is completed and the consignment is created in MetaPack, the MAO/MAWM MetaPack App sends a request to MetaPack to provide the additional customs documentation (if required).
A user may wish to change the shipping method or undo the packing due to reasons such as damage to the package or order cancelation. If a consignment was created in MetaPack and now the tracking number will not be used, MetaPack requires a Void request to remove or invalidate the package from a carrier’s open manifest.
Note: The user can only void the package if the package has not been manifested.
The MAO/MAWM MetaPack AP runs a scheduled job to send a manifest request to MetaPack to mark the open consignments as ready to manifest. Alternatively, the base End of Day UI can be utilized to generate the EOD request per carrier. The actual manifesting is handled by Metapack through Delivery Manager and is not communicated back to MAO/MAWM.
Note: It is up to the Manhattan project team & customer to define the preferred approach (scheduler or End of Day UI) as part of the project. It is advised to only use one of these methods.
ProShip is an industry-leading multi-carrier shipping solution that integrates seamlessly with host systems to handle all small parcel, LTL and TL shipments.
Manhattan Active Omni is not integrated with ProShip out of the box. This integration enables communication with ProShip by altering the base functionality in the following ways:
When a user completes a package in SI&F, a ship request is generated, which communicates the service level, ship from and ship to address and other relevant package information. This ship request is translated to the ProShip required format with the expected data for ProShip to select the carrier and generate the shipping label. The ProShip response is translated back to the Store Fulfillment format where the tracking number is saved against the package, and the 4 X 6 PNG shipping label is saved in the document repository to be printed with the pack slip.
Rate Shopping allows ProShip to compare carriers and service levels that meet the expected commitment date and ultimately choose the lowest-cost method to ship a package. If enabled, the rate shop ship via is sent to ProShip instead of the service level, which allows ProShip to perform rate shopping.
A user may wish to undo the packing process for a fulfillment or package due to reasons such as damage to the package or order cancelation. If a tracking number will not be used due to the user canceling the packing process, SI&F sends a void request to ProShip who removes or invalidates the package from a carrier’s open manifest.
Purolator is one of Canada’s leading integrated freight, package and logistics solutions provider.
Manhattan Active Omni is not integrated with Purolator out of the box. This integration enables communication with Purolator by altering the base functionality in the following ways:
When a user completes a package in SI&F (Store Inventory & Fulfillment Module), a tracking number is assigned to the package in transit to the customer. This tracking number is stored on the order and displayed on the call center UIs to provide updated delivery information to the call center agent. SI&F makes a call to Purolator in the Purolator required format with the expected data, including a list of SI&F’s in transit tracking numbers, for Purolator to respond with the latest tracking information on each. Based on the response for each tracking number, SI&F makes corresponding updates to the tracking details on the order, in addition to updating the order to ‘Delivered’ status upon final confirmation of delivery.
When a return order is confirmed, MAO makes a return shipment request to Purolator and Purolator responds with a return tracking number. SI&F sends a subsequent request to Purolator using the tracking number provided in order to obtain the return label. The return tracking number is stored in MAO and the return label is stored in doc management to be retrieved by the external system sending the email to the customer. The customer prints the label and uses it to ship the product back to the return center.
UPS Mail Innovations Returns is a contractual postal returns solution that offers convenience and efficiency to clients’ customers by enabling them to return their orders through the United States Postal Service.
Online Orders, bridged into MAO, can be fulfilled by a Distribution Center or a Customer Store. Out of the box, Manhattan Active Omni Store Fulfillment supports FedEx and UPS carrier integrations. This integration extends the base-supported parcel integration with UPS by adding:
This feature facilitates integration with UPS Mail Innovation Returns to generate return labels for each package fulfilled by Manhattan Active Omni Store Fulfillment Application.
The United States Postal Service (USPS) is a vital delivery platform that enables American commerce by providing service to every American business and address.
This integration enables communication with USPS by altering the base functionality in the Manhattan Active Omni Store Fulfillment Application in the following ways:
When a user completes a package in SI&F, a ship request is generated, which communicates the service level, ship from and ship to address and other relevant package information. This ship request is translated to the USPS required format with the expected data for USPS to generate the shipping label. The USPS response is translated back to the Store Fulfillment format where the tracking number is saved against the package, and the 4 X 6 PNG shipping label is saved in the document repository to be printed with the pack slip.
When a user completes a package in SI&F, a tracking number is assigned to the package. SI&F compiles the list of open tracking numbers and calls USPS in the required format for status updates on each package. USPS responds with the latest tracking information on each. If the carrier status is configured as ‘In Transit’ in MAO, the package is updated to ‘In Transit’ and the fulfillment is updated to Shipped.
This is a service exposed to allow for MAO to call and cancel a label printed with USPS when the store associate requests to reprint the label with an updated Carrier and/or Service Level value. This service can either be invoked directly via API call or through an additional extension at the desired event point.
This service allows retailers to schedule reoccurring pickups if their store locations are eligible for the service (based on address). This service allows you to check for pickup availability and to schedule USPS to pick up a shipment. When a store location has at least one package manifested with USPS express shipping, a Pickup Availability Request is made to determine whether pickup service is available that day at the given store location. Based on the response, a package pickup schedule request call is made.
Manhattan Active Omni solution provides clients the ability to integrate with a 3rd party external promotions engine to apply automatic promotions as well as promotions tied to a coupon code during order capture or order edits. As changes to the order are made, a new promotion call can be triggered and the discounts associated to the applied promotions are saved on the order and used in order total calculations. These discounts can be applied against the order, specific order lines, specific charges, and directly against the item price.
Manhattan Active Omni has pre-built apps with many 3rd party Promotion Engines which can be leveraged out of the box. Please see each 3rd party vendor to view what functionalities are available.
Oracle’s Relate is a CRM system which is used to manage coupons and promotions and offers services to redeem coupons. The system consuming the coupon is expected to make use of these services.
Manhattan Active Omni is not integrated with Relate out of the box. This integration enables communication with Relate by altering the base functionality in the following ways:
When a new order is created or an existing order is edited to add a serialized coupon in Manhattan Active Omni, MAO makes call to receive the serialized coupon status from Oracle CE.
The feature offers a service to initiate coupon redemption call for one or more serialized coupons in a transaction after the coupons are deemed valid.
In the scenario where an order is cancelled, or a line is cancelled, Manhattan Active Omni makes a call to Oracle CE to void the applied coupon(s).
Sales Force Commerce Cloud (SFCC) has a pricing and promotions offering called ‘OCAPI’ which is used by customers for their Web/ Call Center orders to determine the pricing and promotions.
Manhattan Active Omni is not integrated with SFCC OCAPI out of the box. This integration enables communication with OCAPI by altering the base functionality in the following ways:
SFCC is used to manage all types of promotions, as well as pricing of the items for the included order types under this integration. SFCC provides a single pricing and promotions engine to have a consistent way of evaluating pricing and promotions across different B2C/B2B channels. This includes evaluating order promotions, coupons, item promotions, pricing, and shipping promotions. Coupons added by the CSR in the UI are evaluated and, if eligible, are applied to the basket. These promotions are applied to a Customer Order via a REST-service call to SFCC OCAPI. SFCC determines if the coupons are eligible (making an internal call to external system for validation) based on the basket details of the order and responds with the applied promotion(s) details and value.
The basket calculation web-service call is triggered whenever an update is made on the order that impacts promotion eligibility (Ex. Add Item/Cancel line, Add Coupon, Enter Shipping Information, Quantity Update). The out-of-the-box MAO UI is utilized to display the promotion details to the CSR. Configuration for MAO to delete the basket is also available as SFCC OCAPI has a limit on the number of open baskets for a given customer.
This feature adds the ability to bypass MAO Shipping Charge Calculation and instead use SFCC OCAPI for evaluating and apply shipping charges.
As many clients do not maintain the SFCC Customer ID as the main Customer ID in MAO, the SFCC Customer ID needs to be provided back on the first basket call, which MAO stores on the order in an extended attribute. This value is then sent as the Customer ID in all subsequent basket calls to OCAPI.
XCCommerce provides a state of the art suite of applications that enable complex promotion and coupon capabilities across all channels and provide a seamless and consistent customer experience at all points of purchase.
Manhattan Active Omni is not integrated with XCCommerce out of the box. This integration enables communication with OCAPI by altering the base Point of Sale functionality in the following ways:
When a store associate is browsing items from the item global search or product catalog in Manhattan Active Omni Point of Sale module, it is important to enable them with promotion information to help upsell to the customer. Whenever an item is selected from the global search or product catalog, this App generates the ‘PEM-L’ call to XCCommerce to return back the eligible promotions for the item to display to the user.
When the store associate is making updates to the Point of Sale cart, such as adding or removing an item or adding a coupon, the cart must be re-evaluated for eligible promotions. MAO generates a ‘PEM-P’ call to XCCommerce to apply any eligible promotions to the cart. The response is translated to the MAO required format to update the cart.
Manhattan Active Omni solution provides integration out of the box with Vertex to calculate estimated taxes during order creation, order edits, and final taxes upon invoicing. Some customers may wish to integrate with a different 3rd party tax engine to calculate taxes.
Manhattan Active Omni has pre-built apps with many 3rd party tax engines which can be leveraged out of the box. Please see each 3rd party vendor to view what functionalities are available.
OneSource is a tax software that integrates seamlessly with host systems to provide quotation and invoice tax detail information for customer order transactions.
Manhattan Active Omni allows for base-supported tax integration with Vertex Tax Management. This integration enables communication with OneSource by altering the base functionality in the following ways:
When an order is created or edited in Manhattan Active Omni’s Call Center module, a quotation tax call is generated for the order so the appropriate authorized amount of a payment tender can be secured. This quotation tax call is translated to the OneSource required format with the expected data for OneSource to provide the quotation tax calculation. The OneSource response is translated back to the Manhattan Active Omni format where the jurisdiction-level tax details are saved against the order and order line(s).
When an order is shipped in Manhattan Active Omni, an invoice tax call is generated for the order in, so the appropriate amount of the provided payment tender can be settled against. This invoice tax call is translated to the OneSource required format with the expected data for OneSource to provide the invoice tax calculation. The OneSource response is translated back to the Manhattan Active Omni format where the jurisdiction-level tax details are saved against the order and order line(s).
When an order is refunded in Manhattan Active Omni, an invoice tax call is generated for the order in so the appropriate amount of the provided payment tender can be settled against. This invoice tax call is translated to the OneSource required format with the expected data for OneSource to provide the invoice tax calculation. The OneSource response is translated back to the Manhattan Active Omni format where the jurisdiction-level tax details are saved against the order and order line(s).
Taxware is a continuous and connected platform for tax determination, e-invoicing compliance, and tax reporting to governments around the world. All these services are offered as part of a single cloud-based platform.
This feature adds integration with Taxware to facilitate Manhattan Active Omni to calculate Quotation, Invoice, and Return taxes.
When an order is created or modified using Manhattan Active Omni’s Customer Service or Point of Sale Solutions, a quotation tax call is generated instead of the order so the appropriate authorized amount of a payment tender can be secured. This quotation tax call is translated into the format required by Taxware and comprises all the details that Taxware needs to calculate the quotation tax amount. The Taxware response is then translated back to the Manhattan Active Omni format, and the tax details are saved against the order and the respective order line(s).
When an order is shipped in Manhattan Active Omni, an invoice tax call is generated to calculate the tax at the time of shipment so that the appropriate amount can be settled against the provided payment tender. This invoice tax call is translated to the format required by Taxware and comprises all the details needed by Taxware to perform the invoice tax calculation. The Taxware response is then translated back to the Manhattan Active Omni format, and the tax details are saved against the order and the corresponding order line(s).
When an order is returned in Manhattan Active Omni, a return invoice tax call is generated against the order so that the appropriate amount can be refunded to the customer. This return invoice tax call is translated into the format mandated by Taxware and contains all the details that Taxware needs to calculate the return invoice tax amount. The response is then translated back to the Manhattan Active Omni format, and the tax details are saved against the order and the respective order line(s).
Avalara is an industry-leading tax solution that integrates seamlessly with host systems to handle all tax calculation needs for eCommerce.
Manhattan Active Omni is not integrated with Avalara out of the box. This integration enables communication with Avalara by altering the base functionality in the following ways:
When an order is created in Manhattan Active Omni’s Customer Service or Point of Sale applications, a quotation tax call is generated for the order so the appropriate authorized amount of a payment tender can be secured. When an order is shipped in Manhattan Active Omni, an invoice tax call is generated for the order so the appropriate amount of the provided payment tender can be settled against. When an order is returned in Manhattan Active Omni, an invoice tax call is generated for the order so the appropriate amount of the provided payment tender can be refunded against.
The tax calls are translated to the Avalara required format with the expected data for Avalara to provide the appropriate tax calculation. The Avalara response is translated back to the Manhattan Active Omni format where the jurisdiction-level tax details are saved against the order and order line(s).
Avalara Tax Rate Download is used to support tax calculation in POS Offline mode. A scheduler is created in Manhattan Active Omni to trigger the Avalara Tax Rate Download API on a configurable schedule. MAO sends the list of store locations to Avalara and Avalara returns the applicable tax rates for all valid Store/Product Class combinations.
