03.18 Support Investigation Flow

Status: draft for discussion

1. Goal

Support and operations users must be able to investigate a transaction quickly without reading logs.

For casino deposits, this is critical because merchant support often needs to explain deposit status to the player quickly.

2. Main Questions

The investigation flow must help answer:

• was the transaction created;
• which merchant, brand, and payment method were used;
• which routing rule matched;
• which execution options were tried;
• why an option was skipped or rejected;
• whether additional customer fields were required;
• whether provider request was sent;
• whether provider callback was received;
• whether provider callback was accepted or ignored;
• whether merchant webhook was sent;
• whether webhook delivery failed or retried;
• whether manual correction happened;
• whether transaction was migrated from legacy system.

3. Merchant-Safe Investigation

Merchant users should see enough information to support their own customers.

Merchant-safe view may include:

• transaction status;
• amount and currency;
• customer reference;
• payment method;
• brand;
• safe timeline events;
• webhook delivery status;
• business error code and description;
• legacy marker.

Merchant-safe view must not include:

• raw provider response;
• hidden provider names;
• hidden SUB MID configuration;
• internal platform-only routing details.

4. Platform Investigation

Platform users with proper access may see deeper details:

• full routing path;
• hidden provider details;
• provider callback validation result;
• ignored, duplicate, rejected, or suspicious callbacks;
• webhook attempts and response summaries;
• configuration version active at processing time;
• manual correction history;
• audit entries related to the transaction.

5. Expected Investigation Experience

The product should help support understand the issue in 1-2 minutes.

The transaction page should not force user to open external logs for normal investigation.

If deeper engineering investigation is required, the product should still provide enough references for the engineering team.

6. Common Investigation Cases

The product must make these cases clear:

• transaction rejected because no route matched;
• transaction rejected because velocity limit was exceeded;
• transaction waiting for provider result;
• provider callback was ignored because status is unsupported;
• provider callback was suspicious because amount or currency did not match;
• webhook failed and is retrying;
• manual correction changed final status;
• migrated transaction is read-only and has no new processing events.

7. MVP Success for This Flow

This flow is successful when platform support can explain what happened to any MVP transaction using Back Office only.