Message Type/Transaction Type

The 'Transaction Type' in the MPI request informs Paydee’s MPI Server on what the request is.

Headers
method: POST
content-type: application/x-www-form-urlencoded

Form Data
MPI_TRANS_TYPE:

The subsequent sections describe the different Transaction Type supported.

SALES

You should initiate a request with this transaction type, when you wanted to initiate payment

E.g

i. Key Exchange

ii. Request

[MPI Server will render the Payment Page.]

[You might have additional approved payment methods, too. If you want more payment method, do speak with our sales.]

If you are building your own payment page that fits your brand visual. You should render your payment page & collect payment detail before performing the following sequence.

i. Key Exchange

ii. Request

Note: Make sure you sent the payment method accordingly

For Card payment, the MPI server would authenticate the cardholder. During authentication:

i. Checks the 3DS version the card is enrolled in

ii. Initiate challenge/frictionless flow

VOID (VSALES)

Void a SALES transaction. Use Refund for transaction that has been settled.

REFUND

To refund for transaction that has been settled. You may perform partial refund.

INQUIRY (INQ)

This message checks the status of a transaction. Merchants are highly recommended to implement INQ before re-attempting a new SALES when the following occurs:

i. No response (time out)

ii. Cardholder closes browser

The transaction status will be returned in MPI_ERROR_CODE field

ERROR CODE CODE DEFINITION

000

 Transaction Successful

001

 Transaction Failed

002

 Transaction Was Cancelled

003

 Transaction Has Expired (Time Out)

004

 Transaction In Progress

PRE/INIT RECURRING (PRERECURR/INITRECURR)

These 2 transaction types are part of Paydee’s Split Payment API. They are used to initialise Recurring (subscription) Payment. When the MPI Service receives this request, it will authenticate the cardholder. During the authentication:

i. MPI checks the 3DS version the card is enrolled in

ii. MPI initiates challenge/frictionless flow

Message Type Settlement Schedule

PRERECURR

 No

INITRECURR

 Yes (End of the day - 11 p.m.)

The cardholder will receive notification from the Issuing Bank that RM1.00 (or another amount set by the merchant) has been charged on his/her card.

The RM1.00 will be returned to the cardholder if the message type is PRERECURR because the transaction will not be settled.

Important control parameters for PRERECURR/INITRECURR.

CONTROL USES

Frequency

 Controls interval between payments (in days)

Expiry

 Controls when the split payment arrangement shall end

Count

 Controls the maximum number of payments

Maximum Amount

 Controls the maximum payment amount

Total Amount

 Controls the accumulated payment amount

Terminate

 Terminates the split payment

These messages should be triggered from the cardholder’s browser.

RECURRING

This recurring event attempts to charge the cardholder for the services they subscribe to at predefined intervals. This should be triggered automatically by the Merchant’s Application Server at the right interval without cardholder intervention. The cardholders might receive a notification from their Issuing Bank that their card has been charged.

INIT INSTALLMENT (INITINSTL)

This is part of Paydee’s Split Payment API. Use this transaction type to initiate Installment Payment. Installment Payment is prefered if the amount and number of payment (installment) is known.

When the MPI Service receives this request, it will authenticates the cardholder. During the authentication:

i. MPI checks the 3DS version the card is enrolled in

ii. MPI initiates challenge/frictionless flow

Important control parameters for INITINSTL

CONTROL USES

Frequency

 Controls interval between payments (in days)

Expiry

 Controls when the split payment arrangement shall end

Count

 Controls the maximum number of payments

Maximum Amount

 Controls the maximum payment amount

Total Amount

 Controls the accumulated payment amount

Terminate

 Terminates the split payment

Installment (INSTL)

This recurring event attempts to charge the cardholder for the agreed installment payment at predefined intervals. This should be triggered automatically by the Merchant’s Application Server at the right interval without cardholder intervention. The cardholders might receive a notification from their Issuing Bank that their card has been charged.

TERMINATE

This terminates an installment payment programme prematurely.

PREAUTH

This transaction type is triggered from the cardholder's browser. It is used when the final amount may not be known in advance. The amount pre-authorised will not be settled immediately. It is primarily used to authenticate the identity of the cardholder and check if the cardholder has sufficient credit to complete the payment later.

SALES COMPLETE (SALESCOMPL)

This message is used to finalise the PREAUTH transaction and charge the cardholder with the final amount. If the final amount exceeds the initial PREAUTH amount by 20%, the transaction will be rejected. Therefore, we recommend merchant to:

i. Track & monitor cardholder spending. Perform a SALESCOMP to complete the transaction and reinitiate another PREAUTH.

ii. PREAUTH with a pre-agreed amount and any additional incurred amount.

The merchant can always SALESCOMPL with an amount that is less than the PREAUTH amount.

Message Table

Download the message file here or use the table below to guide you what to pack in the MPI Request message.

SALES
VSALES
(VOID)
REFUND
INQ
(Inquiry)
PRE/INIT RECURR
(Initialize Recurring)
RECURR
(Recurring)
INITINSTL
(Initialize Installment)
INSTL
(Installment)
TERMINATE
(Cancel Split Payment)
PREAUTH
SALESCOMPL
(Sales Complete)
MPI_TRANS_TYPE M M M M M M M M M M M
MPI_MERC_ID M M M M M M M M M M M
MPI_PAN C C C C
MPI_PAN_EXP C C C C
MPI_CVV2 C C C C
MPI_CARD_HOLDER_NAME M M M M
MPI_PURCH_AMT M M M M M M M M M M M
MPI_PURCH_CURR M M M M M M M M M M M
MPI_TRXN_ID M M M M M M M M M M M
MPI_ORI_TRXN_ID M M M M M M M
MPI_PURCH_DATE M M M M M M M M M M M
MPI_ADDR_MATCH O O O O O O O O O O O
MPI_BILL_ADDR_CITY C C C C C C C C C C C
MPI_BILL_ADDR_STATE C C C C C C C C C C C
MPI_BILL_ADDR_CNTRY C C C C C C C C C C C
MPI_BILL_ADDR_POSTCODE C C C C C C C C C C C
MPI_BILL_ADDR_LINE1 C C C C C C C C C C C
MPI_BILL_ADDR_LINE2 C C C C C C C C C C C
MPI_BILL_ADDR_LINE3 C C C C C C C C C C C
MPI_SHIP_ADDR_CITY O O O O O O O O O O O
MPI_SHIP_ADDR_STATE O O O O O O O O O O O
MPI_SHIP_ADDR_CNTRY O O O O O O O O O O O
MPI_SHIP_ADDR_POSTCODE O O O O O O O O O O O
MPI_SHIP_ADDR_LINE1 O O O O O O O O O O O
MPI_SHIP_ADDR_LINE2 O O O O O O O O O O O
MPI_SHIP_ADDR_LINE3 O O O O O O O O O O O
MPI_EMAIL M M M M M M M M M M M
MPI_HOME_PHONE C1 C1 C1 C1 C1 C1 C1 C1 C1 C1 C1
MPI_HOME_PHONE_CC C1 C1 C1 C1 C1 C1 C1 C1 C1 C1 C1
MPI_WORK_PHONE C1 C1 C1 C1 C1 C1 C1 C1 C1 C1 C1
MPI_WORK_PHONE_CC C1 C1 C1 C1 C1 C1 C1 C1 C1 C1 C1
MPI_MOBILE_PHONE C1 C1 C1 C1 C1 C1 C1 C1 C1 C1 C1
MPI_MOBILE_PHONE_CC C1 C1 C1 C1 C1 C1 C1 C1 C1 C1 C1
MPI_RESPONSE_TYPE O O O O O O O O O O O
MPI_RECURRING_FREQUENCY M M
MPI_RECURR_EXPIRY M M
MPI_RECURR_MAX_CNT M M
MPI_RECURR_MAX_AMT M M
MPI_RECURR_MAX_TOTAL M M
MPI_MAC M M M M M M M M M M M

Effective 12 February 2024, Visa requires merchants to provide these data fields to authenticate the cardholders.

Rule #1. Merchants must capture and send the billing address, except in countries where the billing address field does not exist:

  • MPI_BILL_ADDR_CITY
  • MPI_BILL_ADDR_STATE
  • MPI_BILL_ADDR_CNTRY
  • MPI_BILL_ADDR_POSTCODE
  • MPI_BILL_ADDR_LINE1
  • MPI_BILL_ADDR_LINE2
  • MPI_BILL_ADDR_LINE3

Rule #2. Merchants must capture and send:

  • MPI_EMAIL
  • MPI_CARD_HOLDER_NAME

Rule #3. At least contact number (work, home or mobile) should be provided:

  • MPI_HOME_PHONE
  • MPI_HOME_PHONE_CC
  • MPI_WORK_PHONE
  • MPI_WORK_PHONE_CC
  • MPI_MOBILE_PHONE
  • MPI_MOBILE_PHONE_CC