Operator and circle context
Use supported discovery or client-supplied context before presenting a recharge request.
Mobile recharge
Mobile recharge APIs with operator-aware validation.
Submit eligible prepaid recharge requests through approved aggregators with operator context, idempotent processing and transaction-level reconciliation.
PayDrion
Mobile recharge request
Prepaid flow
Illustrative product operating view
Operator and circle context before processing.
POST
/v1/mobile-recharge200"reference": "pd_demo_48291",
"capability": "mobile_number",
"state": "validated",
"evidence": true
Operator
Validated
Circle
Submitted
Amount
Final state
Validated
Submitted
Final state
Mobile recharge API
A timeout must not become an accidental duplicate recharge.
PayDrion applies idempotency, current partner context and final-state tracking to eligible prepaid recharge requests.
Duplicate protection
Apply client references and idempotency when network outcomes are uncertain.
Final-state evidence
Track processing, success, failure and reversal using aggregator references.
Mobile recharge API
Mobile rechargeDedicated product layer · shared PayDrion evidence model
A timeout must not become an accidental duplicate recharge.
PayDrion applies idempotency, current partner context and final-state tracking to eligible prepaid recharge requests.
Mobile rechargeDedicated product layer · shared PayDrion evidence model
PayDrion product architecture
Prepaid flow
Mobile number
Use supported discovery or client-supplied context before presenting a recharge request.
Validated
Operator
Apply client references and idempotency when network outcomes are uncertain.
Submitted
Circle
Track processing, success, failure and reversal using aggregator references.
Final state
Amount
Use supported discovery or client-supplied context before presenting a recharge request.
Validated
PayDrion evidence lineRequest · decision · partner reference · signed event · operator action
Programme boundary
API availability does not equal permission to operate the underlying regulated service.
Activation requires an eligible business model, authorised partner structure, documented operating responsibilities and applicable customer-protection controls.
Where it fits
Designed around the job the money movement must complete.
Configuration follows the real transaction purpose, customer experience and operating responsibility—not a one-size-fits-all product label.
01
Retailer apps
02
Consumer fintech
03
Assisted commerce
Questions
Practical answers before implementation.
Commercial and technical details are confirmed for the specific entity, use case and approved programme.
How does implementation begin?+
PayDrion first maps your business model, transaction flow, expected volumes, risk profile and required payment rails. An implementation plan and test credentials follow successful onboarding.
Can this be enabled for every business?+
Availability, limits, pricing and settlement timelines depend on onboarding, use case, bank or network partner approval, and applicable regulation.
How are transaction states confirmed?+
Use the synchronous API response for immediate context, then rely on signed webhooks and server-side status verification as the operational source of truth.