This API facilitates "transactions" to deliver value to beneficiaries, such as mobile airtime top-ups and data bundles. A transaction progresses through distinct status stages, as illustrated in the following diagram
Final Statuses for Transactions
A final status is a status after which there are no further statuses. Note that SUBMITTED 5 and CONFIRMED 2 are NOT final statuses.
---
config:
theme: neutral
fontSize: 16
look: neo
layout: fixed
---
flowchart LR
B@{ label: "<b>CREATED</b><br><span style=\"font-size: 2em;\">1</span>" } -- "<span style=color:>POST<br>/transactions<br>/[id]<br>/confirm</span>" --> C@{ label: "<b>CONFIRMED</b><br><span style=\"font-size: 2em;\">2</span>" }
C -- "<span style=color:>Sent to<br>receiving<br>partner</span>" --> D@{ label: "<b>SUBMITTED</b><br><span style=\"font-size: 2em;\">5</span>" }
D --> E@{ label: "<b>COMPLETED</b><br><span style=\"font-size: 2em;\">7</span>" }
E -- "<span style=color:>Callback</span>" --> F@{ label: "<b>REVERSED</b><br><span style=\"font-size: 2em;\">8</span>" }
B -- "<span style=color:>Callback</span>" --> G@{ label: "<b>REJECTED</b><br><span style=\"font-size: 2em;\">3</span>" }
B -- "<span style=color:>Callback<br>POST<br>/transactions<br>/[id]<br>/cancel</span>" --> H@{ label: "<b>CANCELLED</b><br><span style=\"font-size: 2em;\">4</span>" }
D -- "<span style=color:>Callback</span>" --> I@{ label: "<b>DECLINED</b><br><span style=\"font-size: 2em;\">9</span>" }
B@{ shape: rounded}
C@{ shape: rounded}
D@{ shape: rounded}
E@{ shape: rounded}
F@{ shape: rounded}
G@{ shape: rounded}
H@{ shape: rounded}
I@{ shape: rounded}
style B fill:#FFFFFF,stroke:#1D8DF0,stroke-width:3px
style C fill:#FFFFFF,stroke:#1D8DF0,stroke-width:3px
style D fill:#FFFFFF,stroke:#1D8DF0,stroke-width:3px
style E fill:#FFFFFF,color:#000,stroke:#90ee90,stroke-width:3px
style F fill:#FFFFFF,stroke:black,stroke-width:3px
style G fill:#FFFFFF,stroke:#f08080,stroke-width:3px
style H fill:#FFFFFF,stroke:#f08080,stroke-width:3px
style I fill:#FFFFFF,stroke:#f08080,stroke-width:3px
- Two-Step Flow:CREATED 1 → CONFIRMED 2
- This approach is used when the initiator needs a short delay (e.g., to collect payment) between creating the transaction and submitting it to DT One.
- The maximum allowed time between the CREATED 1 and CONFIRMED 2 statuses is 60 minutes.
- If the transaction is not confirmed within 60 minutes, it will be automatically canceled.
- One-Step Flow: Create a Confirmed transaction
- This approach is used by DT Shop, where transactions are created and confirmed in a single step.
Before a transaction is sent to the provider, the DT One platform performs several validation checks, including:
- Availability - sufficient balance in the initiator’s wallet
- Provider/Operator availability
- Mobile Number eligibility
If all checks are successful, the transaction is submitted for processing. The maximum time between CONFIRMED 2 status and SUBMITTED 5 status is 10 seconds. At this step, the API may reject a transaction for various reasons, such as exceeding fraud limits or insufficient balance. If rejected, the transaction moves to the REJECTED 3 status. Once the transaction is sent to the provider and undergoes processing, it remains in the SUBMITTED 5 status. Note that SUBMITTED 5 status is not a final status.
- Transaction reachesSUBMITTED 5 status.
- An immediate hold is placed on the initiator’s wallet for the wholesale price of the product.
- If Status changes toCOMPLETED 7
- The wholesale price is deducted from the wallet.
- If Status remainsSUBMITTED 5
- The balance remains on hold.
- If Status changes toREVERSED 8, REJECTED 3, or DECLINED 9
- The hold is released, and the wallet balance is adjusted accordingly.
Once submitted, the transaction is sent to the respective service provider (e.g., mobile operator, gift card provider, etc.). The transaction remains in the SUBMITTED 5 status while the provider processes it. This process typically takes up to 30 seconds, but in rare cases, the provider may delay the response. The maximum time between SUBMITTED 5 status and COMPLETED 7 status is 24 hours. By this time, the transaction will either have a status of COMPLETED 7 or DECLINED 9.
When the provider confirms transaction completion, the status changes to COMPLETED 7, indicating that the digital value has been delivered—either as a mobile recharge or a PIN code for redemption. This information is provided immediately in the callback response.
- Standard API Integration
- FULL CONTROL
- Initiator must handle the callback by listening for updates and processing the response accordingly.
- Low Code Solution
- UI SDK - Faster Deployment Synchronous mode enabled for UI SDK.
- No Code Solution
- DT Shop - Self-Service Platform
- Callbacks are automatically interpreted, and a human-readable result is presented to the DT Shop user.
If the provider is unable to complete the transaction, the status changes to DECLINED 9, and an error code is included in the callback response.
For error handling, refer to the Status and Errors section to determine resolution steps.
Once a transaction reaches its final state, DT One sends a callback notification to the predefined URL (for Standard API integrations and Low Code Solutions) or processes the response internally (for No Code users of DT Shop).
-
Standard API Integration
- The callback must be handled programmatically by listening for updates and processing the response accordingly.
-
No Code Solution
- The platform automatically interprets the callback and presents a human-readable result to the user.
- Recharge Products
- Transaction status
- Relevant error code (if DECLINED 9 status)
- PIN-Based Products
- PIN Code and Serial Number
- Redemption instructions (if applicable)
These details should be stored and presented to the end-user through the appropriate channel (e.g., UI, email, or SMS), depending on the initiator's process for product delivery.
Transaction Updates and Retrieval:
When a callback URL is configured, the API sends real-time updates as the transaction status changes.
You can query the current transaction status using either the id returned by the API or your provided external_id.
The external_id is essential for retrieving transaction details in exceptional scenarios, such as when an API response is not received.
