Midtrans
Inconsistent order_id between Payment Notification and /status API Response
Hi Midtrans team,
I noticed a discrepancy in the order_id field between the payment notification (webhook response or getResponse() from the library) and the /v2/{order_id}/status API response.
This issue started occurring after I successfully enabled the DANA payment channel.
Example: From payment notification logs from Dashboard
From getResponse or /status endpoint:
Other fields like transaction_id, gross_amount, status_code, payment_type, etc., are consistent across both responses. Only the order_id is mismatched. This causes confusion in our order tracking logic, since we rely on a consistent order_id for reconciliation and matching user transactions.
let me confirm, so the issue is:
- getResponse (from library-> Notification.php) and from the "the /v2/{order_id}/status API" is different for dana only ya?
I think this is because dana is from Snap Bi, so we have different formatting. can you show me your implementation when using the getResponse or Notification related code from the library? did you do any mapping?
Yes, the main issue is that the response from the /v2/{transaction_id}/status endpoint returns an order_id field that has the same value as transaction_id.
My current workaround is to get the order_id directly from the notification payload if Payment_type is Dana, not from the Notification object returned from the status API.
Is this issue only happening in sandbox mode?
Yes, that’s correct — the issue is that the order_id field contains the same value as the transaction_id when I receive the response using getResponse() from the library. This problem occurs in the production environment, not in the sandbox.
The temporary solution I received from the Midtrans team is to handle this case specifically in the payment notification handler. When the payment_type is Dana, I make a custom curl request and include the header transaction-source: SNAP_API.
This request is essentially the same as what the Midtrans library performs, but with the additional header, it allows me to get the correct order_id that matches the actual transaction — resolving the mismatch between order_id and transaction_id.