Deprecation of 3DS 1.0 Request Parameter
As of mid-October 2022, 3DS 1.0 support was phased out. However, some Merchants are still using it during the Create Token process, causing 3DS authentication failures.
We are deprecating the 3DS 1.0 parameter to ensure smooth payment processing.
What You Need to Know:
Previously, using 'secure:true' during Create Token indicated the need for 3DS authentication before the Charge API call. Midtrans would proceed with the card token, but 3DS 1.0 authentication would be denied.
Now, please note that the 'secure:true/false' parameter will be entirely ignored by Midtrans. Instead, Midtrans will return the card token without the 3DS 1.0 redirect URL because the 3DS 1.0 flow has been deprecated. For 3DS authentication, merchants are required to follow the existing 3DS 2.0 contract: https://docs.midtrans.com/reference/card-feature-3d-secure-3ds.
Merchant Action Items:
- Do not use the ‘secure:true’ parameter during Create Token.
- Follow the existing contract for 3DS 2.0, which can be reviewed here: 3DS 2.0 Contract:
- Ensure that the ‘authentication:true’ parameter is included during the charge process. Failure to do so will result in Midtrans marking the transaction as a Non-3DS transaction.
- Sandbox Environment: Deprecation of 3DS 1.0 request parameters is scheduled for 18 September 2023.
- Production Environment: Deprecation of 3DS 1.0 request parameters is scheduled for 21 September 2023.
Please take immediate action to update your integration and avoid disruptions in payment processing. For more details on creating tokens, please refer to our Token Creation Guide: https://docs.midtrans.com/reference/get-token.
Currently, card principals (VISA, MASTERCARD, JCB, AMEX) do not process 3DS version 1 transactions anymore. Cards that do not support 3DS version 2 will be rejected on the principal side. However, we are still processing 3DS version 1 transactions although the transactions will be denied on the principal side.
Starting on 9th February 2023, all transactions using 3DS version 1 card will be denied on the
/charge API before it goes to principal.
Midtrans is sanitizing order id characters for MPGS to make sure it's URL safe. Allowed symbols in order id are dash(-), underscore(_), tilde(~), and dot(.).
On Midtrans MAP (Merchant Portal), order id shown will be the same with the one sent by Merchant. but order id shown on MPGS portal or Bank settlement report could be different because of order id sanitization.
For more details, refer Transaction Details Object.
Starting on 1st February, 2018,
channel parameter from Get Card Token request and Charge API request will be permanently removed. Once it is effective, any
channel parameter sent to Midtrans will be disregarded. We advise you to remove
channel parameter on your end immediately.
Following this announcement, we have made
channel parameter as optional. However, should you choose to do a transaction via MIGS banks, you will need to send
bank parameter to Midtrans. Otherwise it will return an error. A few instances where the changes may be applicable are given below.
|No||No||any non-MIGS bank||✅|
|No||MIGS||specific MIGS bank||✅|
|No||Non-MIGS||specific non-MIGS bank||✅|
|MIGS||No||any MIGS bank||❌|
|MIGS||MIGS||specific MIGS bank||❌|
We are improving our API to meet your security needs. Currently, Mandiri ClickPay API payload consists of full PAN number which pose a risk of leaking customer's card credentials.
We are introducing new flow for Mandiri ClickPay. This new flow will enable you to exchange customer card data for a
token_id on client side. Consequently, the
token_id is passed as Mandiri ClickPay parameter instead of
We highly recommend you to update your Mandiri ClickPay implementation to cater this new flow since we are going to deprecate the old implementation by 1st December, 2017.
Starting from 1st November, 2017, we are limiting the characters to make sure that
order_id are URL safe. Allowed Symbols are dash(-), underscore(_), tilde (~), and dot (.). For more details, refer Transaction Details Object.
Starting from 15th January, 2017, we are going to prohibit the use of decimal value for
gross_amount. Few examples of valid and invalid values are given below.
gross_amount will be rejected with a
status_code:400 (validation error).
User-Agentheader in the HTTP notification from Midtrans will no longer be 'Veritrans'. It will be the same as the HTTP client we are using in code. Please do not use the
User-AgentHeader or depend on it.
In line with the change of the name of the organization, we will also deprecate the usage of
veritrans.co.iddomain in the next 3-4 months. The changes in the domain names are listed below.
Please switch to using the new host names and URL's immediately to avoid failures.