GET
/
users
/
{user_id}
/
orders
/
{id}
cURL
curl --request GET \
  --url http://localhost:8080/users/{user_id}/orders/{id}
{
  "account_id": "<string>",
  "amount": {
    "value": 123
  },
  "created_at": "<string>",
  "id": "<string>",
  "last_modified_at": "<string>",
  "source": "<string>",
  "user_id": "012345678901",
  "wallet_txn_data": {},
  "external_status": "<string>"
}

Path Parameters

​
user_id
string
required

User ID

​
id
string
required

Order UUID (also the value sent to Juspay as order_id)

Response

Current order status

​
account_id
string
required
​
amount
object
required
​
created_at
string
required
​
id
string
required
​
last_modified_at
string
required
​
source
string
required
​
user_id
string
required

A validated 12-digit numeric user identifier.

Every external entry point validates:

  • JSON Deserialize runs [UserId::parse] (outer whitespace trimmed, length and digit-only enforced) via #[serde(try_from = "String")].
  • DB FromSql runs [UserId::parse] on every row read.

Display / Deref<Target = str> / AsRef<str> / Into<String> are derived via derive_more — the inner String is pass-through for every read-only borrow, display, and move-out.

Example:

"012345678901"

​
wallet_txn_data
object
required

Lifecycle status of the wallet-side transaction attached to an order.

Wallet-agnostic — today PBA, tomorrow any other wallet integration. The lifecycle has five observable states:

  • Initiated — order row inserted; no wallet call has been made yet. Set at row create-time. Single-phase (interactive add-money) advances straight to Success; two-phase (mandate-autopay) advances to Pending.
  • Pending(deposit_id) — two-phase Phase 1 succeeded: the wallet provider accepted the deposit and returned its id, but it is still parked on the provider side waiting for an external settlement signal. Carried between the Juspay /txns ack and the /orders/{id}=Charged reconciliation.
  • Success(deposit_id) — terminal: the deposit has been finalised at the wallet provider (Phase 2 confirm, or single-phase commit). The provider's id is the single dedup signal for any further status poll.
  • Voided(deposit_id) — terminal: a parked Pending deposit was explicitly released back to the source because the originating charge reached a terminal failure. The provider's id is preserved for audit.
  • Failed — terminal: the originating charge failed before any wallet-side deposit was held (Phase 1 never ran or itself failed).

Serialized to text as:

  • initiated → Initiated
  • pending:<deposit_id> → Pending(deposit_id)
  • success:<deposit_id> → Success(deposit_id)
  • voided:<deposit_id> → Voided(deposit_id)
  • failed → Failed
​
external_status
string | null