Deployment Notice

February 9, 2023

Card transactions that are made using a card that is still using outdated 3DS version 1 will be denied immediately on Midtrans when merchants send /charge API request, to prevent from proceeding it to Card Principal’s network (Visa, MasterCard, JCB, Amex). Midtrans will only proceed normally if the card supports 3DS version 2. With main benefits of improving processing time & efficiency.

As compared to before: Midtrans would still proceed with 3DS version 1 card, even though Principal no longer supports 3DS version 1 (cards that do not support 3DS version 2 will be rejected). This would often result in rejection on the Principal side instead, which is less efficient.

{
  "status_code": "402",
  "status_message": "Cards with 3DS version 1 or lower are not supported. Please retry with another card that supports the minimum 3DS version 2.",
  "id": "dc948e9d-21c1-438d-9e4d-6ee5268b2ac7"
}

August 30, 2022

The allowed maximum time of expiry for GoPay is now adjusted to 7 days.

June 17, 2022

Starting on 22nd July, 2022, we are going to Implement 8 Digit bin.

📘

Note: 8 Digit Bin

With the oncoming mandates from Visa and other principals, Midtrans will start supporting 8-digit BIN's for card transaction processing flows.

The 8-digit bin changes on CoreAPI and will impact the length of token_id and format of saved_token_id.

Changes list:

1. Change on token_id length from 48 digit to 50 digit.

2. Change on saved_token_id format.

3. Change of masked_card in response body, event, and notification.

4. Support 8 digit bin in Midtrans Fraud Detection System/Aegis.
5. Support 8 digit bin in BIN API.

October 7, 2022

Starting on 7th Oct 2022, all MIGS MID has been migrated to MPGS MID.

❗️

Migrate MIGS to MPGS for BCA & BRI except Maybank

In relation to 3DS2.0 mandate from principal, we need to migrate all of existing BCA and BRI MID from MIGS to MPGS because MIGS BCA & BRI only support 3DS 1.0

The MID migration will affect channel_response_code and channel_response_message format.

For more MPGS response details, please refer to MPGS Response code

Affected Banks:

if you have any inquiry, please contact [email protected]

December 6, 2022

GoPay Deny Error

Starting in January 2023 there will be an update on Midtrans deny error for GoPay payment channel. The transition phase will start in January upto April 2023, Please ensure that merchant's system can accommodate both behavior (before and after) within this period.

🚧

Update on behavior of Midtrans deny errors for GoPay payment channel.

Midtrans will change the behavior of Midtrans deny error for GoPay payment channel - Some of GoPay error will be mapped to Midtrans error (4xx/5xx) - GoPay error that is mapped to 4xx error won’t have HTTP post notification.

{
"Status_code":"202",
"status_message":"GoPay transaction is denied",
"channel_response_code":"201",
"channel_response_message":"insufficient balance"
…
}

{
  "status_code":"400",
  "status_message":"One or more parameters in the payload is invalid.",
  "validation_messages":[
    "Gopay.account_id is required"
  ],
  "id":"1a3fef7b-c034-4cf2-98d6-e239594976f3"
}

{
  "status_code":"500",
  "status_message":"Sorry. Our system is recovering from unexpected issues. Please retry.",
  "Id":"6a782ad4-1e18-4df5-b5bd-dbf94ce15ddc"
}

Change List :

1. Update on behaviour for listed GoPay errors below :

2. GoPay error that is mapped to 4xx error won’t have HTTP post notification.

Expiry Threshold

Starting on January 16th 2023, we will apply minimum and maximum expiry time threshold.

🚧

New minimum and maximum expiry time threshold

Midtrans will apply minimum and maximum expiry time threshold on all payment channels. - Transaction with expiry time less than 20 seconds will be rejected. - Transaction with expiry time more than 180 days will be accepted, but expiry time will be trimmed to 180 days*

*except for GoPay transaction. GoPay have maximum expiry time of 7 days

Change list:

1. Added field expiry_time on charge response, get status response and notification. expiry_time field will be returned in API response (charge and status API) and also HTTP notification

{
   "transaction_time":"2023-01-16 10:00:00",
   "Transaction_status":"pending",
   "transaction_id":"ce0a3584-5a0c-4049-ad88-5590a96be4fe",
   …
   "expiry_time":"2023-07-16 10:00:00"
}

{
   "transaction_time": "2023-01-16 10:00:00",
   "transaction_status": "pending",
   "transaction_id": "ce0a3584-5a0c-4049-ad88-5590a96be4fe",
   "status_message": "midtrans payment notification",
   …
   "expiry_time":"2023-07-16 10:00:00"
}

2. Transaction with expiry time less than 20 seconds will be rejected

Sample scenario of Charge API with Custom Expiry object :

a. charge request without order time
If merchant send the sample request (seen on right side) without order_time at 10:00:30 GMT+7, then the calculated expiry time is 10 seconds, as follow:

• order_time: not specified hence will follow transaction time
• transaction_time: 10:00:30 GMT+7
• expiry_duration : 10 seconds
• Expiry timestamp: 10:00:40 GMT+7
• Expiry time: 10 seconds

Therefore the transaction will be rejected.

b. charge request with order time
If merchant send the sample request (seen on right side) with order_time at 10:00:30 GMT+7, then the calculated expiry time is 10 seconds, as follow:

• order_time: 10:00:00 GMT+7
• transaction_time: 10:00:30 GMT+7
• expiry_duration: 40 seconds
• Expiry timestamp: 10:00:40 GMT+7
• Expiry time: 10 seconds

Therefore the transaction will be rejected.

"custom_expiry": {
  "expiry_duration": 10,
  "unit": "second"
}

"custom_expiry": {
  "order_time": "2023-01-16 10:00:00 +0700",
  "expiry_duration": 40,
  "unit": "second"
}

{
   "status_code": "400",
   "status_message": "One or more parameters in the payload is invalid.",
   "id": "1a1a66f7-27a7-4844-ba1f-d86dcc16ab27",
   "validation_messages": 
       [
           "custom_expiry is below minimum threshold"
        ]
}

3. Transaction with expiry time more than 180 days will be accepted but expiry time will be trimmed to 180 days (except for GoPay transaction which is 7 days)

Sample scenario of Charge API with Custom Expiry object :

a. charge request without order time
If merchant send the sample request (seen on right side) request at 2023-01-16, then the calculated expiry time is 210 days, as follow:

• order_time: not specified hence will follow transaction time
• transaction_time: 2023-01-16 10:00:00 GMT+7
• expiry_duration : 210 days (approx 7 months)
• Expiry timestamp withouth trim should be: 2023-08-16 10:00:00 GMT+7

We will trim the expiry time to 180 days with new expiry timestamp: 2023-07:16 10:00:00 GMT+7.

b. charge request with order time

If merchant send the sample request (seen on right side) request at 2023-01-16, then the calculated expiry time is 209 days, as follow:

• order_time: 2023-01-15 10:00:00 GMT+7
• transaction_time: 2023-01-16 10:00:00 GMT+7
• expiry_duration: 210 days (approx 7 months)
• Expiry time: 209 days
• Expiry timestamp withouth trim should be: 2023-08-15 10:00:00 GMT+7

Therefore we will trim the expiry time to 180 days with new expiry timestamp: 2023-07:16 10:00:00 GMT+7.

"custom_expiry": {
  "expiry_duration": 210,
  "unit": "day"
}

"custom_expiry": {
  "order_time": "2023-01-15 10:00:00 +0700",
  "expiry_duration": 210,
  "unit": "day"
}

{
  "transaction_time":"2023-01-16 10:00:00",
  "transaction_status":"pending",
  "transaction_id":"ce0a3584-5a0c-4049-ad88-5590a96be4fe",
  ....
  "expiry_time":"2023-07-16 10:00:00" 
}