Payment orchestration · Lifecycle, routing and failure safety

The 60-second model#

A payment orchestrator presents a unified integration while selecting/interacting with payment providers according to merchant configuration and eligibility. It must normalize results without losing provider-specific meaning. Merchant UX success, an orchestration API response, PSP authorization, capture and bank settlement are different observations.

Interviewers can assess whether you recognize financial integrity and unknown outcomes, not whether you have memorized a provider's API. The supplied JD establishes orchestration and multiple PSPs; the model below is general and must be checked against actual product contracts.

Participants and identifiers#

Do not use “transaction ID” without identifying its system and grain. One payment may have several attempts, captures or refunds. A duplicate at one grain may be legitimate at another.

Lifecycle and invariants#

Illustrative state graph: CREATED → PENDING → REQUIRES_ACTION / AUTHORIZED / DECLINED; AUTHORIZED → CAPTURED / VOIDED; refund has its own lifecycle. This is not an OMNO state specification. Ask whether automatic capture exists, which transitions are terminal, and how partial operations are represented.

Invariants: captured total does not exceed the authorized/allowed total under the contract; refunded total does not exceed eligible captured amount; currency is preserved; events do not duplicate ledger effects; tenant A cannot read/refund tenant B's payment; historical audit facts are not erased by a later state change.

Routing and fallback decisions#

Provider health, geography, currency, cost or historical acceptance can be possible routing inputs in an orchestrator. The JD does not confirm which OMNO implements. Present them as questions or hypothetical test dimensions.

Ambiguous timeout: the highest-value scenario#

Scenario: PSP A may have accepted a payment, but the orchestrator timed out before receiving its response. A second attempt through PSP B could create a duplicate charge.

Ideal reasoning: distinguish “not sent,” “explicitly declined,” and “sent but unknown.” Retain operation/attempt/provider references and query the supported PSP/reconciliation path. Keep an explicit unknown/pending state if necessary. Apply only the documented, enforced idempotency/retry/fallback policy. Verify late success/decline callbacks, callbacks arriving after a retry decision, duplicate events and one logical financial effect.

// Standalone decision model, illustrative policy rather than a payment engine.
export type Attempt =
  | { kind: 'not-submitted'; reason: string }
  | { kind: 'declined'; retryAllowed: boolean }
  | { kind: 'unknown'; reference: string }
  | { kind: 'succeeded'; reference: string };
export function nextAction(attempt: Attempt): string {
  switch (attempt.kind) {
    case 'not-submitted': return 'consult-fallback-policy';
    case 'declined': return attempt.retryAllowed ? 'consult-retry-policy' : 'stop';
    case 'unknown': return 'reconcile-original-attempt';
    case 'succeeded': return 'record-success';
  }
}

Wrong: “Retry until the payment passes.” Right: “Determine whether the first attempt committed and follow the agreed safe-retry contract.” An idempotency key at the orchestrator boundary does not automatically deduplicate two different providers unless the system implements that coordination.

Amounts, currency and concurrency#

Do not compare decimal currency with floating-point equality after repeated arithmetic. Use integer minor units or a defined decimal library; currency scale varies and must come from the contract. Check minimum/maximum/zero/negative values, precision, unsupported currency, large values, rounding rules, and JSON serialization limits. Do not assume every currency has two decimal places.

// Standalone exercise: amounts already expressed in declared integer minor units.
export function canRefund(captured: number, refunded: number, requested: number): boolean {
  const values = [captured, refunded, requested];
  if (!values.every(Number.isSafeInteger)) return false;
  return captured >= 0 && refunded >= 0 && requested > 0 && refunded <= captured &&
    requested <= captured - refunded;
}

The function checks a local invariant only. Two concurrent refunds can each pass a stale client-side check and together exceed the remaining balance. A backend transactional/concurrency mechanism must enforce the invariant. Test competing requests against one deliberately owned payment and inspect accepted totals and conflict responses.

3DS, redirects and sensitive data#

3-D Secure authentication can introduce browser challenges/redirects and asynchronous outcomes; it is not the same as card authorization or a guarantee of successful payment. In provider sandboxes test frictionless/challenge success, challenge failure, cancellation, timeout, return URL tampering and refresh/back behavior. Do not promise a specific challenge path for every issuer/provider.

Use only test-mode provider instructions and approved synthetic tokens. Prevent raw card/security-code data from appearing in logs, traces, screenshots, URLs or assertions. Do not store payment secrets in fixtures or commit saved authentication state. Compliance scope belongs to the actual integration/security process, not an invented interview claim.

A risk-first sandbox matrix#

Interview answer and references#

30 seconds: “For an orchestrator I test routing correctness and financial integrity. I separate authorization, capture and settlement, track payment versus provider-attempt identity, and prioritize duplicate submissions, uncertain PSP timeouts, webhooks and merchant isolation. A timeout is not proof of failure, so I reconcile before another financial attempt.”

Memory hook: one payment, many observations; unknown is not declined. Provider-specific further reading: Stripe idempotency, Stripe webhooks. These illustrate one provider's contract, not OMNO's or every PSP's semantics. Next: test design.

Quick practice#