Menu

TPH production support

How to Diagnose a Failed TPH Payment

Diagnose the journey in order. Prove arrival, find the first failed stage, align timestamps, and control duplicate risk before anyone repairs, replays, or retries the payment.

By T24Guru Editorial··
TPHProduction support

Browse more TPH articles →

Find the stage, not only the status

A current TPH status describes where the platform represents the payment now. It does not always identify where the first failure occurred. Repair, parked, rejected, or complete states can follow an earlier parsing, routing, posting, transport, or acknowledgement problem.

Use a safe internal reference or synthetic test identifier to create one timeline. Record timezone offsets and clock skew before concluding that an event is missing.

End-to-end failure-stage map

StageQuestionEvidence
ArrivalProve that the file, API, OFS, or message reached the expected TPH entry point.Inbound timestamp, channel, safe correlation value, and receipt or listener evidence.
Parsing and validationFind the first structural or business validation that rejected the payment.Original non-sensitive fields, first error, source configuration, and validation result.
Product and routingConfirm the product, route, warehouse, scheme, and processing path selected.Matched conditions, amount, currency, geography, value date, and channel criteria.
Core postingDetermine whether accounting or the core transaction committed, rejected, or has an uncertain outcome.Posting request and response, record state, balances, limits, locks, and commit evidence.
Scheme handoffProve whether the outbound instruction left TPH and was accepted by the next component.Outbound identifier, queue or file evidence, transport result, and handoff timestamp.
AcknowledgementSeparate a missing acknowledgement from a failed payment.Scheme response, status update, correlation mapping, timeout, and late-response evidence.
Repair or retryUnderstand why work entered repair and whether another attempt is safe.Original attempt, repair reason, retry count, ownership, duplicate controls, and approval.

A safe diagnostic sequence

  1. Define impact: one payment, one channel, one product, or a broad service failure.
  2. Preserve original evidence: capture statuses, timestamps, errors, queue or file state, and recent changes before intervention.
  3. Prove arrival: identify the earliest TPH-owned evidence for the transaction.
  4. Walk forward: locate the first expected stage that has no evidence or an explicit rejection.
  5. Check dependencies: include core banking, database, messaging, files, certificates, and external schemes only when the journey reaches them.
  6. Determine outcome certainty: classify the original attempt as not started, rejected before commit, committed, handed off, acknowledged, or uncertain.
  7. Repair through ownership: use the approved queue, workflow, and operator role rather than changing records or messages directly.

Duplicate and replay risk

Never infer that a timeout means nothing happened. The caller may have timed out after TPH posted or after a scheme accepted the instruction. Replaying without proving the original outcome can create duplicate accounting, duplicate scheme submission, or a second customer payment.

Escalate uncertain outcomes with the original and current status, all correlation identifiers, posting evidence, outbound evidence, acknowledgement evidence, retry count, and the exact action being proposed.

Evidence before escalation

  • Environment, business date, channel, product, amount/currency category, and impact.
  • Normalised timeline from arrival to the first missing or failed stage.
  • First error and surrounding context, with sensitive values redacted.
  • Core posting, outbound handoff, acknowledgement, repair, and retry state.
  • Recent configuration, deployment, certificate, route, or dependency changes.
  • Whether any restart, retry, release, repair, or manual update already occurred.

Related reading