Callback
Get notified when there is an update for transactions
Callback allows you to receive a notification when a minting or redemption transaction is completed. To use Callback, you must first generate an API Key. Once you have your API Key, navigate to the API Key menu and select the Callback URL tab to set it up.

Enter your Mint and Redeem Callback URLs. You may use a single endpoint for both callbacks if preferred. Once done, click the Save Callback URL button to confirm.

You’ll see a notification in the bottom-right corner once the Callback URL is successfully saved.

You can then use the endpoint to receive callbacks in your logs whenever there’s an update to your mint or redeem transactions. Please refer to the example below.
Delivery rules
These rules apply to both mint and redeem callbacks:
One callback per terminal state. The mint callback fires once when
adminMintStatustransitions toMINTED. If your endpoint is unreachable, the callback is not retried automatically — respond with2xxquickly and process asynchronously on your side.No signature on the outgoing webhook. Reconcile by
merchantOrderIdagainst your own state. Treat the request as untrusted until you've matched it and re-verified via Transaction History API.Body is
application/json. Headers are minimal — only the standardContent-Type.Two mint flavours:
IDRX mint — when
requestTypeis empty or"idrx". Fires after IDRX is minted on-chain.USDT onramp — when
requestTypeis"usdt". Fires after the IDRX→USDT swap and USDT transfer to the destination wallet succeed.
Since callbacks are not retried, missed deliveries must be reconciled by polling the Transaction History API using merchantOrderId.
Mint callback
Payload structure
Every mint callback body has these top-level fields:
id
number
Internal MintRequest ID
paymentAmount
number
Amount the user paid in IDR (before fees)
toBeMinted
string
IDRX amount minted (= paymentAmount minus deducted fees)
merchantOrderId
string
Your order ID
destinationWalletAddress
string
Wallet that received the IDRX or USDT
chainId
number
EVM chain ID
paymentStatus
enum
WAITING_FOR_PAYMENT / PAID / EXPIRED
userMintStatus
enum
PROCESSING / MINTED / NOT_AVAILABLE
adminMintStatus
enum
REQUESTED / PROCESSING / MINTED / REJECTED
txHash
string
On-chain mint transaction hash
reference
string
Payment gateway reference
requestType
string
null / "idrx" / "usdt"
customerVaName
string
Source account name
paymentProviderId
number
Always 1 (POP)
returnUrl
string | null
Echoed back from original request
expiryTimestamp
string
Unix epoch milliseconds
isApproved
boolean
Multisig approval flag
reportStatus
enum
NONE / PENDING / RESOLVED
processByUserId
number | null
Admin processor
qredoTxId
string | null
Safe multisig transaction hash
signedTx
string | null
Solana signed transaction blob
deleted
boolean
Soft-delete flag
createdAt
ISO 8601
Creation timestamp
updatedAt
ISO 8601
Last updated timestamp
TransactionHistory
object
Payment gateway notification
MintRequestTransactionFees
array
Fee breakdown
usdtRequest
object | null
USDT swap details
TransactionHistory sub-object
TransactionHistory sub-objectMintRequestTransactionFees array
MintRequestTransactionFees arrayAn empty array ([]) means the payment channel charges no IDRX-layer fee.
This is expected behaviour, not missing data.
usdtRequest sub-object (USDT onramp only)
usdtRequest sub-object (USDT onramp only)Fee structure by payment method
Two patterns exist depending on the channel:
VA & e-wallet
Fee is added on top at checkout.
paymentAmount === toBeMintedMintRequestTransactionFees = []
QRIS
Fee is deducted from minted IDRX.
toBeMinted = paymentAmount - 0.7%Fee row appears in
MintRequestTransactionFees
Channel
paymentCode
IDRX fee
Charged how
Effect
BNI VA
IQ
3,000 IDR
Added on top
Fees array empty
BRI VA
BR
3,000 IDR
Added on top
Fees array empty
OVO
OV
1.67%
Added on top
Fees array empty
DANA
DA
1.67%
Added on top
Fees array empty
NusaPay QRIS
SQ
0.7%
Deducted
Fee row present
NOBU QRIS
NQ
0.7%
Deducted
Fee row present
Worked example — 100,000 IDR top-up
Channel
User pays
IDRX delivered
paymentAmount
toBeMinted
Fees
BRI VA (BR)
103,000
100,000
100000
"100000"
[]
OVO (OV)
101,670
100,000
100000
"100000"
[]
NusaPay QRIS (SQ)
100,000
99,300
100000
"99300"
[{ "name": "QRIS Fee (0.7%)", "amount": "700" }]
Universal reconciliation formula:
Mint examples
A — IDRX mint via QRIS (SQ)
SQ)B — IDRX mint via BRI VA (BR)
BR)Empty MintRequestTransactionFees on VA payments is expected behaviour.
USDT onramp variant
When requestType === "usdt":
Callback fires after the IDRX → USDT swap completes
Payload shape is identical
usdtRequestbecomes populated
Reconciliation tips
For high-value transactions, verify on-chain delivery using txHash.
Status handling
Always check adminMintStatus.
MINTED
Tokens delivered
Mark success
REJECTED
Expired or rejected
Mark cancelled
anything else
Unexpected
Log and alert
Redeem callback
IDRX
USDT / USDC / USDT0
See also
POST /api/transaction/mint-request — how mint orders are created.
Processing Mint IDRX Requests — end-to-end mint flow with reconciliation pattern.
Transaction History API — pull state by
merchantOrderIdif a webhook is missed.
Last updated