←
Build the decisionSaved automatically
Hard · Grade 122. Production Payment Orchestrator

Manage a 500-transaction production stream across 10 adversarial hidden test scenarios.

Scenario

500 retail, refund, payroll, business, and settlement payments stream through 3 providers.

Problem statement

You are Principal Payments Architect for YamusaPay.

Your switch processes a 500-transaction production stream—retail transfers, refunds, payroll payouts, business disbursements, and international settlements. Providers experience latency spikes, capacity exhaustion, and unexpected outages.

Your system must protect safety invariants: filter incompatible providers, safeguard urgent payroll/high-value payments, handle retries without repeating failed routes, and pass 10 adversarial test scenarios!

Build your decision tree systematically: 1. Eligibility Invariants: Use `canRouteA/B/C` to reject incompatible or offline routes. 2. Service-Level Protection: Route urgent payroll, priority, and near-deadline work to fast, reliable providers. 3. Retry Management: Prevent retrying the same failed provider using `lastProvider` checks. 4. Cost & Congestion Optimization: Spread routine traffic across healthy providers before congestion cascades.

What this teaches

Design an enterprise payment orchestrator balancing real-time telemetry, provider capacity, and retry backoffs.

Evaluation contract

  • Safety invariants and completion: 25%
  • Priority, deadline, and high-value protection: 25%
  • Outage, recovery, congestion, and retry resilience: 25%
  • Cost, throughput, and queue efficiency: 15%
  • Generalization across adversarial distributions: 10%
Scroll down to build and test your solution.

Active controller

Apply & Run executes only the selected controller.

How a rule works

A rule has two parts:

WHEN <something is true> → DO <this action>

  • WHEN is a question about what is happening right now. For example: "Is it raining?" or "Is there a wall ahead?"
  • DO is what happens when the answer is yes.
  • The simulation runs one step at a time.
  • On each step, the rules are checked from top to bottom.
  • The first rule that is true wins. The rules below it are skipped for that step.
  • To change which rule wins, move it up or down the list.
  • If no rule is true, nothing happens on that step.
  • Some actions have more than one step, like "turn right, then move". You build these in the Functions tab.
  • Once a multi-step action starts, it finishes all its steps before the rules are checked again. It only stops early if the next step is not safe.
See an example

Two rules for deciding about an umbrella:

1  WHEN isRaining  → take an umbrella
2  WHEN always     → leave the umbrella at home
  • It is raining. Rule 1 is true, so you take an umbrella. Rule 2 is skipped.
  • It is sunny. Rule 1 is false, so rule 2 is checked next. Rule 2 is always true, so you leave the umbrella at home.
  • Order matters. If rule 2 were on top, it would be true every day, and you would never take an umbrella.

Rule folders

Categorise cards without changing their global execution order.

No rules yet. Nothing will happen until you add at least one rule.