11. MID & Live ID
Banks are the one who process the payments and a payment aggregator is just a layer above those banks. To process transactions, the aggregator has to procure MID (Merchant ID) from the banks and then link those MIDs to the Live ID that of the merchant.
MID Procurement:
To procure MIDs from banks & wallets, the aggregator collects business details & documents and submit to banks in specified formats. In some cases, banks may require additional documents (E.g.: Undertaking letters for IMSL, CITI bank approval)
Banks/wallets reserves the right to issue the MID for a merchant. Sometimes banks may seek additional documents or clarification related to merchant’s business model.
Note: Banks usually refer to Terms of usage, privacy policies, refund/ cancellation policies that are written on merchant’s website/App. So these things are important as it impacts MID issuance and also, come handy as first line of defence against chargebacks
MID issuance policies followed by banks are combination of,
- Guidelines set by card schemes such as Visa, MasterCard, NPCI
- Policies/regulations by RBI and the Government
- Bank’s internal compliance or risk policies
Example: SBI doesn’t issue MID for wallet loading, HDFC acquiring bank doesn’t issue MID for rummy merchants, None of the banks issue MID for Cryptocurrency exchanges
MID Issuance Time:
MID approval process is time consuming and turn around time varies from bank to bank. So procurement of MID may take weeks if not months.
So how an aggregator can manage the delays?
- Have better turn around time with banks for issuance of MIDs
- Every aggregator would have procured industry specific MIDs from banks (basically, an aggregator is a merchant to banks). Aggregator can configure those generic MIDs to start with and replace them with bank approved MIDs
Major challenge in using generic MID: Back-to-back cost of such generic MIDs will be higher so it may not be possible for an aggregator to run the show without making losses
Example: Credit Card rate of generic MID is 1.90% but aggregator’s commercials with merchant is 1.80%. So if generic MID is enabled then aggregator will lose 0.10% of value for every transaction.
Solution: Procure multiple generic MIDs with different pricing from different acquiring banks and configure them intelligently to reduce the loss.
Net-banking approval process works bit differently.
Except 5–6 large banks, all other banks work on carpet approval wherein aggregator issues MID based on its discretion and then shares merchant’s details with banks (if needed). So aggregator can enable 35–30 banks without any approval or delay.
Large banks that provide explicit approval: Allahabad Bank, Axis, Bank of India, CITI, City Union, Corporation, DCB, Deutsche, HDFC, ICICI, IDBI, IndusInd, Kotak, SBI, Yes bank
Why banks gave carpet approval to aggregator?
Most of these banks do not have method or tech capability to issue individual MID for the merchant. They didn’t develop it because they are not big in acquiring side of business. So these banks gave carpet approval to aggregators and work in revenue sharing model.
How do you know in whose name MID is?
Have you ever checked what is the narration in card statement or bank account statement when you do online transaction?
If merchant is configured on its own MID then merchant’s name would appear in the statement. In case merchant is on generic MID or transaction is done on one of carpet approved banks then aggregator’s name will be shown.
Interesting case: Do transaction on PhonePe and sometimes you may see the name FX Mart.
I was involved since the start of FX Mart (Aug’15) till PhonePe (Aug’17)… so will tell you stories on complexities of payment containers when I write about them.
Live ID (issued by aggregator)
Live ID is unique identifier issued by aggregator to a merchant (sometimes they call it MID). As mentioned earlier, bank/wallet issued MIDs are linked to this Live Id.
Transactions, refunds, settlements, chargeback, card vault of a merchant are linked to this unique Live ID. Some of the attributes of Live Id.
Account Configuration. Each Live ID can be configured with one bank account (If merchant require multi-account settlement then use special fields/scheme codes)
Acquiring bank Configuration: Multiple acquiring banks can be configured for one Live Id (helps in configuring performance based routing for cards)
Commercials: One set of rates can be configured for one Live ID
Fee Model: One type of fee model (upfront deduction, Surcharge or Invoicing) can be configured for one Live ID
Example: If a merchant wants to absorb net-banking charges but wants to pass card charges to customer then both upfront and surcharge model cannot be configured on same Live Id.
In such case, merchant will be issued two Live Ids. One Live Id for cards with surcharge configuration and other one for net-banking with upfront deduction configuration. Merchant has to pass appropriate Live Id depending on payment mode selection.
Card Vault: Card vault is linked to the Live Id (ideal case).
Example: A merchant has to Live Ids (A1234 and B6789) then saved card at A1234 will not show in B6789 unless both vaults are merged.
Number of Live Ids: Aggregator can issue multiple Live IDs for a merchant without additional approval from banks
Dashboard: Each live Id will have individual dashboard
Challenge: If a merchant has 10 Live Ids then merchant will have 10 dashboards to refer to. So to make merchant’s life simple, aggregator should provide ‘Master Dashboard’ to combine all Live Ids under single umbrella.
Next: Payment Page
