Need a custom solution?

Request Demo



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.

Transaction Type Summary

Quick reference for all supported transaction types.

Transaction Type MPI_TRANS_TYPE Purpose Triggered By Typical Use Case
Sales SALES Initiate a payment and render checkout page Cardholder browser One-time checkout (FPX, e-Wallets, Cards)
Void VSALES Cancel an unsettled SALES transaction Merchant server Order cancelled before settlement
Refund REFUND Refund a settled transaction (partial or full) Merchant server Returns, failed fulfilment
Inquiry INQ Retrieve current transaction status Merchant server Timeout recovery, browser closed
Pre-Recurring PRERECURR Validate card and initiate recurring setup (no settlement) Cardholder browser Subscription card validation
Init-Recurring INITRECURR Initialise recurring payment with settlement Cardholder browser Start subscription billing
Recurring RECURR Charge card automatically at intervals Merchant server Trigger a subscription billing event
Init-Installment INITINSTL Initialise installment payment Cardholder browser Fixed installment plans
Installment INSTL Charge installment amount Merchant server Scheduled installment billing
Terminate TERMINATE End recurring or installment programme Merchant server Cancel subscription or plan
Pre-Authorization PREAUTH Reserve amount without settlement Cardholder browser Hotels, tours, variable pricing
Sales Complete SALESCOMPL Finalise PREAUTH with actual amount Merchant server Complete variable amount charges

SALES

Triggered from Cardholder Browser

Use this transaction type to initiate a payment and render the checkout page.

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 methods, 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)

Triggered from Merchant Server

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

REFUND

Triggered from Merchant Server

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

Void/Refund Reference Table
Payment Channel Void/Refund/Both Cut-off time for void request Processing Method Credit to buyer within
Credit/Debit card Both 11:30pm GMT+8
Boost Both 11:59pm GMT+8 Auto 1-business day
TnG e-Wallet Both 11:59pm GMT+8 Auto 1-business day
Grab Pay Both 11:59pm GMT+8 Auto 1-business day
Maybank QR Push Refund Manual 7-business day
Alipay Both 11:59pm GMT+8 Auto 1-business day

INQUIRY (INQ)

Triggered from Merchant Server

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)

Triggered from Cardholder Browser

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

Triggered from Merchant Server

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)

Triggered from Cardholder Browser

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

L
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)

Triggered from Merchant Server

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

Triggered from Merchant Server

This terminates an installment payment programme prematurely.

PREAUTH

Triggered from Cardholder Browser

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)

Triggered from Merchant Server

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