Oracle NetSuite
 Merchant-Initiated Transactions

The MIT mandate ensures that merchants, acquirers, and issuers understand the transaction processing cycle. The MIT framework introduces a global standard for identifying transaction intent and whether a transaction is merchant initiated (without participation of cardholder).
The MIT framework facilitates exemptions from Strong Customer Authentication (SCA) using 3-D Secure depending on the transaction context (such as recurring transactions or Mail-Order/Telephone-Order (MOTO) transactions).

Benefits of Complying with the MIT Mandate

Merchants, acquirers, and issuers can link a series of related transactions.
  • MIT transactions—token-based transactions in particular, have better approval rates when the issuer can identify them.
  • MIT and token-based transactions can be processed without strong customer authentication (these transactions might otherwise fail, especially in regions complying with PSD2).
  • Transaction transparency, which results in higher authorization rates and improved cardholder experience.

Supported MIT Transaction Types

The MIT transaction types mentioned below are industry-specific transactions supported by the plugin:
  • Resubmission: A merchant resubmits transactions that request authorization but were declined due to insufficient funds while the goods or services were already delivered to the cardholder. A merchant in this situation can resubmit the request to recover outstanding debt from cardholders.
  • Reauthorization: A merchant initiates a reauthorization when the original order or service is not complete or fulfilled within the authorization validity limit set by the scheme. Common instances that require reauthorizations include delayed shipments, split shipments, extended stays, and extended rentals.
  • Delayed Charges: A delayed charge is associated with an agreement between you and the cardholder for services rendered. Merchants might use delayed charges after providing services such as lodging, travel, or auto rental.
  • No Show: A no-show transaction occurs when you and a cardholder have an agreement for a purchase, but the cardholder does not meet the terms of the agreement. No-show transactions are often used in hotels or restaurants where bookings are not honored despite the agreement entered into by the cardholder.
  • Unscheduled/Auto Top-up: This type of transaction uses a stored credential for a fixed or variable amount and does not occur on a scheduled or regularly occurring transaction date. The cardholder must provide consent for the merchant to initiate one or more future transactions.
If a MIT type is not selected, the transaction is flagged and processed as MOTO by default.
To avoid issues processing a MIT with a custom role, you must provide the payment instrument permission to the role. The
Payment Type
 field is supported only when the Payment Instrument feature is enabled.
Follow these steps to assign the role:
  1. Go to
    Setup
    .
  2. Click
    Users/Roles
    , and click
    Manage Roles
    .
  3. Click
    Customize
     on the role you want to assign the permission to.
  4. Scroll down, and under the Permissions tab, click the
    Lists
     subtab.
  5. Find the
    Payment Instrument
     row and set permission level to
    Full
    .
  6. Click
    Save
    .

Initial Authorization of External Merchant Initiated Transactions

Follow these steps to trigger
subsequentAuth
 instead of
subsequentAusubsequentAuth
 and
authFirst
 for payment card tokens imported into
Oracle NetSuite
.
  1. Go to
    Cybersource Integration
     >
    SuiteApp Configuration
    . Click
    SuiteApp Configuration
    .
  2. On the top navigation, hover over
    Configuration
     >
    Reporting
    .
  3. Click the
    Payment
     tab.
  4. In the
    Payment Network Reference
     field, select
    MOTO transaction
    .
Oracle NetSuite Merchant-Initiated Transactions