API Reseller
DMT API
Sender registration by OTP, beneficiary management with name verification, and transfer submission. Regulatory per-sender limits are enforced in the API rather than left to your application to remember.
What you get
- Sender registration and OTP verification endpoints
- Beneficiary add with bank name verification
- Per-sender monthly limits enforced server side
- Automatic refund on a confirmed failure
- Transaction status polling and webhooks
The contract
- Auth
- Issued credentials per key pair, over TLS. Signed requests where the rail requires it.
- Sender
- Registration and OTP verification are separate endpoints.
- Beneficiary
- Add returns the bank-verified account name before any transfer is allowed.
- Limits
- Per-sender monthly caps enforced server side, not left to your application.
- Failure
- A confirmed refusal refunds automatically. An unknown outcome does not.
- Webhook
- Signed, with replay protection. Retried until your endpoint returns 2xx.
- Environments
- Sandbox mirrors production semantics, including failures.
FAQ
About dmt api
What happens if a transfer fails after the sender has handed over cash?
A confirmed refusal reverses automatically and the amount returns to the operator's wallet. An unknown outcome does not reverse, because the money may have reached the beneficiary. It stays pending until the rail confirms which of the two happened.
Do I have to track the monthly per-sender limit myself?
No. Limits are enforced server side and a transfer that would breach one is refused at submission with a specific error. You can display remaining headroom, but you are not responsible for computing it — an application that tracks limits locally will drift from the authoritative count.