Overview

The Inquiry Details endpoint enables merchants to retrieve extended transaction data associated with a specific transaction.

This endpoint provides additional transaction information beyond the standard Status Inquiry APIs response structure and is intended for operational, reconciliation, and investigative use cases.

The Inquiry Details endpoint complements the Status Inquiry APIs and is used together with the Status Inquiry APIs to provide complete transaction visibility.

For the architectural role, positioning, and operational usage model of the Inquiry Details API, refer to E.2.10 – Inquiry Details API.

Endpoint Definition

GET <ROOT_URL>/payments/{transactionID}/status/details

Path Parameters

Authentication

The Inquiry Details endpoint requires authentication using a Bearer token.

Authorization: Bearer <AuthToken>

This endpoint must be invoked server-to-server and must never be called directly from client-side applications.

Token Characteristics

• The token is generated and managed via the SIBS Backoffice
• The token is static and does not expire under normal operation
• The token must be securely stored and treated as a credential
• Invalid or missing tokens will result in authentication errors

The Bearer token must be configured prior to performing any API operations.

Headers

Request Characteristics

• Method: GET
• Request Body: Not applicable
• Idempotency: The operation is idempotent and can be safely repeated without side effects
• Operational Use: Suitable for backend data retrieval, operational analysis, and investigation workflows

Example Request

Example Request

GET <ROOT_URL>/payments/{transactionID}/status/details
Authorization: Bearer <AuthToken>
X-IBM-Client-Id: <clientid>
Content-Type: application/json
Accept: application/json

Response Overview

The response contains extended transaction metadata and contextual information associated with the specified transaction.

This may include additional metadata, contextual information, and attributes not present in the standard Status Inquiry APIs response structure.

The structure and content of the response may vary depending on:

• Payment method
• Transaction type
• Processing context

Integrators must implement defensive parsing and must not assume the presence of specific optional fields.

Integrators should design response processing logic to remain compatible with future extensions and payment-method-specific variations.

Operational Considerations

Use of transactionID

• The transactionID is the only supported identifier for retrieving transaction details
• Merchants must persist this value at transaction creation time
• The merchantTransactionID must not be used for transaction retrieval operations

Data Retrieval Scope

• The endpoint returns extended transaction metadata and contextual information associated with the specified transaction.
• This information may include additional metadata, contextual data, and lifecycle-related attributes beyond the standard status response.
• This endpoint must not be used to determine the current or final transaction state.

For more details, refer to:

• E.2.2 – Status Inquiry Endpoint Specification
• E.2.6 – Consistency Model: Query vs Webhook

Relationship with Status Inquiry APIs

The Inquiry Details endpoint provides extended transaction data, while the Status Inquiry APIs remain the mechanism for retrieving the latest transaction state available through the query API.

The Inquiry Details endpoint must not be used as a substitute for Status Inquiry APIs when determining transaction outcomes.

For transaction-state validation, refer to E.2.2 – Status Inquiry Endpoint Specification.

Error Handling

• Always evaluate both:
  • HTTP status code
  • returnStatus.statusCode
• A 200 OK response does not necessarily indicate a successful payment
• Transaction outcome should be validated using Status Inquiry APIs when no final webhook is available or when additional confirmation is required

Refer to:

• C.5 – Status Codes and Error Codes Catalogue
• E.2.8 – Error Handling and Edge Cases

Key Integration Principles

• Use Status Inquiry APIs for transaction-state validation when no final webhook is available or when additional confirmation, reconciliation, recovery, or inconsistency resolution is required
• Use Inquiry Details only for extended data retrieval
• Do not rely on this endpoint for business-critical decision making
• Correlate all requests using transactionID
• Handle optional and variable response structures defensively
• Ensure secure handling of authentication credentials

Summary

The Inquiry Details endpoint provides extended transaction visibility and complements the Status Inquiry APIs.

It enables access to additional transaction data required for operational, reconciliation, and investigative use cases, while preserving the Status Inquiry APIs as the mechanism for retrieving the latest transaction state available through the query API.

When used correctly in conjunction with the Status Inquiry APIs, it enhances transaction observability without affecting core transaction lifecycle validation.