Investigate transaction activity
Trace an order from creation through routing, authentication, payment, capture, void, or refund in DEUNA Admin.
On this page
Use transaction activity when an order is pending, rejected, delayed, or behaving differently from the merchant integration. DEUNA Admin combines a business-level payment history with technical request and response records so operations and integration teams can investigate the same transaction without switching tools.
Transaction activity is read-only. Viewing an event does not retry a request, change an order, or contact a payment processor.
Before you begin#
Your role must include the View Orders section permission. Confirm the selected merchant and environment before you search; records are scoped to that context.
Have at least one identifier available:
- Order ID or order token
- Transaction ID
- Customer email, when permitted by your privacy policy
- Approximate creation date
If you cannot open Payments > Orders, ask an Admin user to review your roles and permissions.
Choose the right view#
Order details provide two related investigation surfaces. Start with View history, then use Technical when you need the underlying exchange.
| Surface | Best for | What it shows |
|---|---|---|
| View history | Understanding the payment lifecycle | Order creation and updates, payment creation and status changes, routing, 3DS, and fraud events with the fields relevant to each event. |
| Technical | Diagnosing an integration or provider exchange | Recorded transaction events, HTTP method and destination, response code, request and response data, timestamps, and available request, trace, and span identifiers. |
| Activity Logs | Auditing actions performed by Admin users | Who changed a configuration or performed an Admin action. Activity Logs do not represent the payment execution trace. |
Access transaction activity#
- Sign in to DEUNA Admin.
- Select the merchant and environment associated with the transaction.
- Open Payments > Orders.
- Search by Order ID or email, or use the date and payment filters to narrow the list.
- Open the row actions menu and select View details.
- For the lifecycle summary, select View history. For transaction activity, open Technical.
If the order has no recorded technical events, Technical displays No technical activity. This does not by itself identify the cause or payment outcome.
Follow the payment history#
Select View history from the order detail header. The history is presented as a timeline, with the newest recorded event first.
The exact fields depend on the event:
| Event | Evidence you can expect |
|---|---|
| Order created | Initial amount, currency, and order status. |
| Order updated | Current order and payment status. |
| Payment created | Payment amount and currency. |
| Payment status updated | Payment status and applicable processor, authorization, capture, refund, or error details. |
| Routing generated | Applied rule and path, plus the payment or fraud provider represented by that route. A routing decision can create more than one timeline entry. |
| 3DS updated | Authentication status, 3DS provider, and an error code or message when one was reported. |
| Fraud analysis | Available provider, decision, risk, evaluation, or shadow-mode details. |
Do not treat an intermediate event as the final financial result. For example, successful 3DS authentication allows payment processing to continue, but it does not mean that the payment was authorized or captured.
Inspect technical events#
Open Technical. This view has two areas: Activity and Data.
Technical activity in DEUNA Admin. All merchant, user, provider, identifier, timing, and payload values in this example are fictional.
What the Technical view contains
| Area | What appears there | How to use it |
|---|---|---|
| Order context | Order total, order and payment statuses, last update, order token, Order ID, and Customer ID. | Confirm that you opened the correct order and environment before interpreting an event. |
| Activity controls | Recorded-event count, sort control, event-name search, and three grouping modes: None, Request, and Trace. | Reduce a long transaction trace to the events related to the operation you are investigating. |
| Group header | Group type, shortened Request ID or Trace ID, event count, and the sum of recorded execution time for the events in that group. | Expand or collapse related checkpoints and compare one request or trace with another. |
| Activity checkpoint | Response-code badge when available, event name, event creation time, and recorded log timestamp. | Select the checkpoint that best matches the failed, delayed, or unexpected stage. |
| Exchange summary | HTTP or protocol method, destination, Request ID, Trace ID, and Span ID. Available identifiers include copy controls. | Correlate the event with merchant logs, provider evidence, or a DEUNA Support investigation. |
| Data viewer | Request and Response tabs, response-code badge, an elapsed-time value when available to your role, and formatted payload data with a copy control. | Compare the outgoing data with the returned result. Copy only the minimum safe evidence required. |
The payload viewer keeps object and field names visible so you can inspect the shape of the exchange. The values and nesting vary by event and provider. A field shown in the example is not guaranteed to appear in every transaction.
Read an event
- Select an event in Activity. On mobile, expand the event instead.
- Review the event name and timestamp.
- Compare the HTTP method, destination, and response-code badge with the operation you expected.
- Switch between Request and Response in Data.
- Record the Request ID, Trace ID, or Span ID when those identifiers are present.
When an event has a 4xx response, DEUNA Admin can display an Error message above the payload. Other response codes remain visible on the event and in the data panel.
The response code describes that technical exchange, not necessarily the final payment outcome. Before fulfilling an order, compare the code with Payment status, View history, and asynchronous status notifications.
Events produced during an order flow
The available activity depends on the path the transaction followed. Common groups include:
| Stage | Examples visible in Activity | What to inspect |
|---|---|---|
| Order | A new order was created; the order was updated | Order identifiers and the status returned to the merchant integration. |
| Routing | Generate payment routing | The selected path and the provider exchanges that follow it. |
| Payment | Generate payment; request authorization | Request amount and currency, processor response, and resulting payment status. |
| Authentication | 3DS evaluation started, challenged, updated, completed, or failed | Whether customer action was required and whether payment processing continued afterward. |
| Address verification | AVS validation, suppression, or reversal | Normalized validation result and the payment action that followed it. |
| Fraud | Generate antifraud engine analysis; shadow evaluation | Provider result and whether the transaction proceeded to payment processing or review. |
| Post-payment operations | Capture, partial capture, refund, partial refund, void, or reversal request | Operation amount and identifier, response, and the later payment-status event that confirms the result. |
Some events record that a stage occurred but do not contain a request or response body. Payload availability varies by operation and provider.
Group and search the trace#
In Activity, use the following controls to reduce a long trace:
- None shows each event in a flat list.
- Request groups events that share a Request ID. Use it to follow the work initiated by one inbound request.
- Trace groups events that share a Trace ID. Use it to follow a transaction across related processing steps.
- Search event filters by the displayed event name.
- Sort activity reverses the event order.
When an event has no value for the selected grouping identifier, DEUNA Admin places it in Orphan. The event can still be useful when its transaction ID, timestamp, and neighboring events match the incident window.
Investigate a failed or delayed payment#
Follow this order so that an intermediate technical error is not mistaken for the final result:
- Confirm the environment, current order status, current payment status, Order ID, and Transaction ID.
- Open View history and identify the last lifecycle event.
- Open Technical and group by Trace.
- Find the matching payment, routing, authentication, fraud, or post-payment event.
- Compare its response code and response data with the next event in the trace.
- Check whether a later status update recovered the payment, moved it to another provider, or confirmed a final failure.
- Compare the final DEUNA status with the status received through your payment webhook.
For a rejection, search the public error-code reference using the DEUNA error code. Provider-specific codes and messages should be interpreted with the applicable provider documentation.
Prepare evidence for support#
When you need DEUNA Support to investigate, provide the minimum evidence required:
- Merchant and environment
- Order ID or order token
- Transaction ID
- UTC timestamp and incident window
- Displayed event name and response code
- Request ID, Trace ID, and Span ID when available
- Current order and payment status
- Expected behavior and observed behavior
Only send an entire raw payload when Support requests it through an approved channel.
Limits and recovery#
- Transaction activity is an observability record, not a replay or retry control.
- Not every stage produces a request and response body.
- Events can arrive after the initial request when a provider reports an asynchronous result.
- Missing activity does not establish whether a provider processed the transaction.
- The current payment or order status is the authoritative Admin snapshot; use webhooks and the applicable API response for integration-side state handling.
If the identifiers and environment are correct but the required event is still absent, gather the evidence above and contact DEUNA Support. Do not repeat a payment operation until you have confirmed that retrying it is safe.