Multi Merchant Support
Note
This feature is supported for only Customers using ADE encryption with Verifone gateway.
In some merchant environments, it is required to support device sharing across multiple processor Merchant IDs (MIDs).
To support that Multi Merchant feature has been introduced where a single payment device is used to process transactions of multiple merchants within the same business environment, each with distinct business identities, credentials, and settlement configurations with providers bank account.
SCA enables multi-merchant support through seamless integration with gateway, allowing transactions initiating from the same physical POS device to be routed to different Merchant IDs (MIDs) or Terminal IDs (TIDs). This is predominantly useful in shared retail environments or franchise locations where multiple businesses operate from a common device.
To support this feature, SCA’s administrative functionality has been enhanced to allow the configuration and management of multiple merchant profiles within a single device. Each merchant profile will be assigned an account number, a device name (optional) and a multi merchant PIN.
Set Up
The Multi Merchant setup implementation initiates from the Host Registration during the Startup scenario, when the Device is Registered with account details on the PWC portal. There is no configuration-based setup for Multi Merchant feature.
Payment Process
Once the application setup is complete for Multi Merchant support, the POS system must include <MMACCOUNT> field in every payment and report request sent to the device. This field specifies the merchant account to which the transaction or report should be processing.
If the POS is not providing <MMACCOUNT> field details as part of the payment or report request, then the application will consider the default MM Account, which is set using DEFAULTMERCHANTACCOUNT parameter, for processing the payment or report request.
In case the DEFAULTMERCHANTACCOUNT parameter is not set then it is mandatory to send the <MMACCOUNT> field details in payment or report request.
If the <MMACCOUNT> field is missing the command request will not process and respond with the defined error codes, refer to Relevant Error Messages for error codes detail.
There is another field is sent as <MMPIN>. The application will validate both the <MMACCOUNT> and <MMPIN> before processing the transaction and in case of invalid data, the application will respond with the appropriate error codes.
The payment command moves forward and process the remainder of the payment transaction using the <MMACCOUNT> specific credentials and merchant details.
Note
Once the setup is complete and multiple merchant accounts are registered, only the first registered merchant account will be used for running the Test Sale.
Note
Multi-merchant feature is applicable to all Payment commands those are using Host request. Refer to the command request section for more details on the field descriptions.
Assumptions
The following assumptions outline the conditions, which required to be considered during the execution of this feature.
- EMV configuration, Tender type configuration, CDT configuration and all similar settings must not be different among the merchants sharing this SCA application instance.
- If Debit is enabled, then all merchants must use the same DUKPT debit key.
- Verifone P2PE Encryption is required to be utilized for encryption and this is the only supported cardholder data encryption mechanism which will be supported with Muti Merchant functionality.
-
- The following encryption methods will be blocked and cannot be configured using Multi Merchant functionality:
-
- VSP
- FISERV TAVE Encryption
- Canadian Interac will be blocked from using Multi Merchant functionality.
Sample Request and Response
Request
Following is an example of request packet
<TRANSACTION>
<FUNCTION_TYPE>PAYMENT</FUNCTION_TYPE>
<COMMAND>CAPTURE</COMMAND>
<TRANS_AMOUNT>1.00</TRANS_AMOUNT>
<MMACCOUNT>1234</MMACCOUNT>
<MMPIN>123456</MMPIN>
<MANUAL_ENTRY>FALSE</MANUAL_ENTRY>
<FORCE_FLAG>FALSE</FORCE_FLAG>
</TRANSACTION>
Response
Following is an example of response packet
<RESPONSE>
<ACCT_NUM>476173******0011</ACCT_NUM>
<COMMAND>CAPTURE</COMMAND>
<APPROVED_AMOUNT>1.00</APPROVED_AMOUNT>
<AUTH_CODE>32427A</AUTH_CODE>
<AUTH_RESP_CODE>91</AUTH_RESP_CODE>
<BANK_USERDATA>VISA</BANK_USERDATA>
<BATCH_TRACE_ID>a1a3beb1-52c4-4ebd-88a8-1f347a02d513</BATCH_TRACE_ID>
<CARD_ABBRV>VI</CARD_ABBRV>
<CARD_ENTRY_MODE>Contactless</CARD_ENTRY_MODE>
<CARD_EXP_MONTH>12</CARD_EXP_MONTH>
<CARD_EXP_YEAR>31</CARD_EXP_YEAR>
<CARD_TOKEN>4761735440810011</CARD_TOKEN>
<CTROUTD>9438</CTROUTD>
<INVOICE>000681</INVOICE>
<DCC_IND>2</DCC_IND>
<DIFF_AMOUNT_DUE>0.00</DIFF_AMOUNT_DUE>
<INTRN_SEQ_NUM>4026910903</INTRN_SEQ_NUM>
<MERCHID>000024885939</MERCHID>
<ORIG_TRANS_AMOUNT>1.00</ORIG_TRANS_AMOUNT>
<PAYMENT_MEDIA>VISA</PAYMENT_MEDIA>
<PAYMENT_TYPE>CREDIT</PAYMENT_TYPE>
<PAR>V0010013820179861073690933044</PAR>
<REFERENCE>50100001</REFERENCE>
<RESPONSE_CODE>91</RESPONSE_CODE>
<RESPONSE_TEXT>CAPTURED</RESPONSE_TEXT>
<RESULT>CAPTURED</RESULT>
<RESULT_CODE>4</RESULT_CODE>
<TERMID>002</TERMID>
<TERMINATION_STATUS>SUCCESS</TERMINATION_STATUS>
<TOKEN_SOURCE>TA</TOKEN_SOURCE>
<TRAINING_MODE>OFF</TRAINING_MODE>
<TRANS_AMOUNT>1.00</TRANS_AMOUNT>
<TRANS_DATE>2025.09.02</TRANS_DATE>
<TRANS_SEQ_NUM>6747</TRANS_SEQ_NUM>
<TRAN_LANG_CODE>EN</TRAN_LANG_CODE>
<TRANS_TIME>10:32:31</TRANS_TIME>
<TROUTD>4026910903</TROUTD>
<COUNTER>92</COUNTER>
<UI_TIME>4.902</UI_TIME>
<HOST_TIME>1.540</HOST_TIME>
<CMD_TIME>9.477</CMD_TIME>
</RESPONSE>
Relevant Error Messages
Transaction Scenario | Result Codes | Response Text |
---|---|---|
MMACCOUNT missing in POS request for Multi Merchant enabled device | 59042 | [MMACCOUNT] field missing |
When MMACCOUNT used does not existing on device | 59046 | Invalid Value for [MMACCOUNT] |
When MMACCOUNT and MMPIN combination is invalid | 59040 | Invalid Combination of [MMPIN] and [MMACCOUNT] |
When MMACCOUNT field is used as TERMINAL_NAME and duplicate record is found | 59082 | Duplicate [MMACCOUNT] name found |