Elavon downloads and stores cookies on your device when you visit our website. We use these cookies to better understand and improve your browsing experience by identifying most visited pages, personalising content, and measuring site performance.

Essential cookies enable core functionality such as page navigation and access to secure areas. The website cannot function properly without these cookies; they can only be disabled by changing your browser preferences.

These are cookies that support site functionality that is visible or advantageous to you or your experience of the site, they enable websites to remember choices and provide a more personalized experience.   Functional cookies help to provide services that you request, such as language preference or layout.

Performance cookies help us to improve our website by collecting and reporting information on its usage (for example, which of our pages are most frequently visited).

These cookies and similar technologies gather information about your browsing habits. They remember that you've visited a website and share this information with other organisations, such as advertisers and platforms on which we advertise. They do this in order to provide you with ads that are more relevant to you and your interests. Although these cookies and similar technologies can track your visits to other websites, they don't usually know who you are. Without these cookies, online advertisements you encounter will be less relevant to you and your interests.

Cookie Settings

U.S. Bank Europe DAC. Registered in Ireland – Number 418442..  Registered Office: Block F1, Cherrywood Business Park, Dublin 18, D18 W2X7, Ireland.
U.S. Bank Europe DAC, trading as Elavon Merchant Services, is regulated by the Central Bank of Ireland.
 
U.S. Bank Europe DAC. Registered in Ireland with Companies Registration Office. The liability of the member is limited. United Kingdom branch registered in England and Wales under the number BR022122.
U.S. Bank Europe DAC, trading as Elavon Merchant Services, is a credit institution authorised and regulated by the Central Bank of Ireland.  Authorised by the Prudential Regulation Authority.  Subject to regulation by the Financial Conduct Authority and limited regulation by the Prudential Regulation Authority.  Details about the extent of our regulation by the Prudential Regulation Authority are available from us on request.

Most popular solutions

Additional solutions

Fusebox integration & options

Optional platform features

Documentation

North America

Europe

Regions

Special Interest Group for IIAS Standards (SIGIS) is a non-profit, membership corporation that is responsible for the development and management of an industry standard to meet IRS requirements for operating an inventory information approval system (an "IIAS"). SIGIS assists merchants, plan administrators, acquirers, card issuers, and processors to help support IRS requirements
for FSA/HRA card programs.


::page-heading-list{min-level=2 max-level=2 }


## IIAS Merchant Certification Program

The IRS requires plan administrators to approve FSA/HRA debit card transactions from a non-health care merchant only when the merchant
supports an Inventory Information Approval System (IIAS). The IIAS system is a combination of inventory management and POS systems that
manage the following three functions:

- Confirms the health care eligibility of items purchased with a FSA or HRA card, by accessing eligibility flags in the merchant’s inventory database when merchandise is purchased with a FSA/HRA card.

- Generates a payment transaction that contains the required IIAS information.

- Supports an information archive system that allows the merchant to respond to an IRS audit as required.

In addition to supporting a system capable of handling IIAS transactions, a merchant must also join SIGIS by completing a Membership Agreement, a Merchant Self-Assessment and Checklist, and Certification with their acquirer.

Merchants that elect to implement an IIAS using the standard published by SIGIS must become members of SIGIS and be certified by SIGIS prior to sending IIAS transactions in the SIGIS-standard format.

Certification requires the following:

- Completion of an IIAS Merchant Self-assessment.
- Technical testing certification by the merchant’s acquirer.
- Use of the SIGIS Eligible Product List.
- Arrangements to support transaction data retention/retrieval.

A merchant's acquirer will review the IIAS Merchant Self-assessment and submit it to SIGIS for approval. A merchant will not be permitted to claim that it supports IIAS transactions using the SIGIS standard until it has been certified to the IIAS standards developed and approved by SIGIS.

Merchants that are clients of a certified third-party service provider may use a simplified certification form.

To obtain a copy of the SIGIS IIAS Technical Specification, SIGIS Members may login to the [Members Area](https://www.sig-is.org/member-login) and download a copy.

## IIAS Merchant Control Number 

After completing a TPS Merchant certification, SIGIS notifies the merchant, its acquirer and payment card networks (MasterCard and
Visa). Upon receipt of the IIAS certification confirmation, the acquirer may request each payment card network to assign an IIAS merchant control number. This number must be included in payment card authorization request messages in addition to the IIAS data fields provided by
merchant/acquirer.

- MasterCard - the merchant control number is called a MasterCard ID (MCID).

- Visa - the merchant control number is called a Merchant Verification Value (MVV).

:::::notice{note}

 SIGIS does not assign the MCID or MVV. The assignment of the MCID or MVV can only be done by the respective payment card network, after the card network receives the request from the merchant’s acquirer.
:::::



### Register as a 90% Rule Merchant

To register as a 90% Rule merchant, merchants must first be a SIGIS Member in good standing and have paid its membership fee. The merchant
will then be able to access the [Members Area](https://www.sig-is.org/member-login) of the SIGIS website to complete the 90% Rule registration for each of the merchant's eligible store locations. The SIGIS 90% Rule Program Implementation Procedures
are also available in the Members Area. This contains information for merchants, acquirers, plan administrators, issuers, and processors about the 90% Rule program.

For Plan Administrators, while offering FSA/HRA cardholders the opportunity to use their cards at registered 90% Rule merchants is
optional, it is a way to increase the convenience and usability of an FSA/HRA card program. Transactions at 90% Rule stores are not
auto-substantiated and plan administrations will need to follow their policies for substantiation of such purchases, most likely asking
cardholders to forward their sales receipts.

### IIAS Versus 90% Rule Comparison

Some drug stores and pharmacies have the option of supporting an IIAS or registering as a 90% Rule merchant. Additionally, plan administrators may elect to support IIAS and/or 90% Rule programs. The chart below highlights some of the key characteristics and requirements of each program.

| Program Description | Merchant IIAS (Includes TPS Merchant) | 90% Rule |
|---------|---------------------------------------|----------|
| Program description | IIAS transactions enable real-time verification that funds approved for debiting an FSA/HRA card account are for eligible medical items, as required by the IRS. Issuer/issuer processors utilize the IIAS data fields in authorization request transactions to approve and auto-substantiate eligible health care amounts. | After successful program registration, 90% Rule merchants accept FSA/HRA payment cards just like any other payment card; there are no additional technical requirements for merchants. Issuers/issuer processors support a list of 90% Rule merchant locations during authorization processing. |
| Qualification requirements | Any merchant that sells prescriptions/Rx or eligible health care items. | Limited to drug stores/pharmacies that have stores whose sales are primarily eligible medical items (90% or more of sales for each store registered must be from prescriptions or eligible health medical items). |
| Technical requirements for merchants | Merchants are required to make technical changes to support the following: Use the SIGIS Eligible Product List to flag eligible health care items in merchant’s inventory. Change payment card processing to add FSA amounts to transactions. Support a list of FSA/HRA BINs to identify card numbers to add IIAS data fields. Store transaction detail for approved FSA/HRA card transactions in the event of an IRS audit. | Drug stores/pharmacies are not required to make any technical changes. |
| Identification of prescription amounts | Yes, IIAS merchants have the option to include the Prescription/Rx Amount in addition to the Total Health Care Amount; this enables plan administrators to approve more FSA/HRA transactions. | Not applicable. |
| Merchant categories | Includes the following: 5411 – Grocery/Supermarket 5310 – Discount Stores 5300 – Warehouse Clubs 5499 – Convenience Stores 5912 – Drug Stores/Pharmacies 5122 - Druggist/Drug Propertaries: 5960 – Drug Stores/Pharmacies 5122 – Druggist/Drug Proprietaries 5960, 5964, 5965, 59691 Online Pharmacies: Various MCC - Other Non-Healthcare Merchants
| Cardholder required to submit a transaction receipt to plan administrator | Because transactions are auto-substantiated, cardholders are most likely not required to submit transaction sales receipts; although it is recommended that cardholders keep copies of transaction receipts. | Cardholders are most likely required to submit transaction sales receipts; cardholders are recommended to keep copies of transaction receipts. |
| Name of merchant list | IIAS Merchant List | 90% Rule Merchant List |
| Transaction data retention | IIAS merchants are required to store the transaction detail for approved IIAS transactions in the event of an IRS audit for 5 years. | Not required. |
| Annual processes | IIAS merchants are not required to re-certify unless the merchant makes changes to software that affects IIAS-certified components or if the merchant changes acquirers. | The IRS requires annual registration and re-attestation that the sales of each registered store location are 90% or more from prescriptions or eligible medical items. |
| For more information | For merchants that operate their own inventory and cash register software, see IIAS Merchant Certification. For merchants that contract with a POS vendor/third-party servicer, see TPS Merchant Certification. | For drug stores/pharmacies that sell primarily prescriptions and eligible medical items, see 90% Rule Merchant Attestation. |

Health Savings Account Cards

Alliance Offers

Data as a Service

Invitation to Apply

Accounts

Bank Holidays

Card Activation

Card Controls

Challenge-Widget

Commercial Credit Cards

Commercial Statements

Credit Card Account Details

Credit Card Accounts Overview

Credit Card Alerts

Credit Card Application Status

Credit Card APRs

Credit Card Balance Transfers

Credit Card Disputes

Credit Card Payments

Credit Card Qualified Offers

Credit Card Statements

Credit Card Transactions

Data Sharing for Marketing Purposes

Digital Wallets

Make a Payment - Coming Soon

Rewards Accelerator

Rewards Automatic Redemption

Rewards: Balance Summary

Rewards: Dashboard

Rewards Redemption Accounts

Rewards Redemptions

Rewards Transactions: Earned and Redeemed

Travel Notifications

User Profile

3DSecure2

Avvance

CheckoutJs

Commerce SDK

Converge

Disputes Management

Dynamic Currency Conversion

eBoarding

Elavon Cloud Payments Interface

Elavon Payment Gateway

Fusebox

Hosted Payment Page

In Person Payments on Opayo

Leads

Lightbox payment modal

Online Payments on Opayo

Opayo

Opayo Direct

Opayo Forms

Opayo Reporting API

Opayo Server

Opayo Shared API

Payment Method Gateway

Payments Core 365

Simplify

viaconex

XML API

Card as a Service API

Core Banking API

Money Movement API

Reference API

Access Online Transactions

Account Transfers

Account Validation

ACH Originations

Bank Information

Card as a Service

Check Payables

Corporate Account Information

Corporate Account Information 3LO

Corporate Credit Cards

Corporate Onboarding

Corporate Statements

Custody

Data Toolbox

Data Toolbox - Accounts

Data Toolbox - Documents

Data Toolbox - Transactions

Debit Card Phone Number Lookup

Disbursements via Zelle®

U.S. Bank Flexible Capital Platform

Freight Payment Customer Profiles

Freight Payment Transactions

Incoming Webhooks

Instant Payments

Investment Accounting

PaySmart

Payee Choice

Payee Token+

Personal Loans

Positive Pay

Push to Card

Receivables

RTP® - Real-Time Payments

Tokenized Payments

Treasury Builder

U.S. Bank FBO Account

Virtual Account Reporting

Virtual Card Payments

Voyager Accounts

Voyager Cards

Voyager Drivers

Voyager Transactions

Voyager Vehicles

Wire Transfers

Fusebox overview

Getting started

Transaction flow

Transaction sequencing

API message format

Reconciliation

Settlements

Transaction types

Authorization Only (01)

Sale Transaction (02)

Prior-Authorized Sale (07)

Return (09)

Void Sale (11)

Batch Close (13)

Batch Create and Inquiry (14)

Void Return (17)

Transaction Inquiry (22)

Token Request (37)

Full Authorization Reversal (61)

Heartbeat (73)

Incremental Authorization (75)

Partial Authorization Reversal (76)

Concepts

Tokenization

Tokenization introduction

Tokenization API fields

Tokenization scenarios

Example transactions

Error scenarios

Retail

Retail scenarios

Retail API fields

Retail examples

Lodging

Lodging transactions

Lodging API fields

Lodging examples

Credential on file transactions

Best practices

Software conversions

Restaurant

Restaurant transactions

Restaurant API fields

Restaurant examples

Restaurant credential on file transactions

Restaurant receipts

MOTO and eCommerce

eCommerce transactions

MOTO and eCommerce API fields

Ecommerce examples

Direct marketing examples

eCommerce credential on file transactions

EMV transactions

Implementation considerations

Certification

EMV API fields

EMV Public Cap Keys, parameters, and reports

Sample files

EMV receipts

EMV integration samples

API-based settlement

Settlement transactions

API-based settlement fields

API-based settlement examples

Check payment

Check transactions

Check API fields

Check payment examples

DCC transactions

DCC transaction flows

DCC API fields

DCC examples

DCC receipt requirements

DCC certification process

Gift and stored value cards

Gift and stored value card transactions