Payment Processing
Fraud check, async authorization with retries, and synchronous ledger recording. Demonstrates predicates to skip unnecessary work, async webhook callbacks, and a goal Step that fans in two upstream outputs.
Scenario
Process a payment with fraud detection, authorization, and ledger recording.
Flow Design
Goals: [record-transaction]
The planner automatically includes check-fraud and authorize-payment since record-transaction depends on them.
Fraud Check Step
- Check transaction against fraud rules
- Predicate: Skip if amount < $5
- Output: risk_score
- Runs first (no dependencies)
Authorization Step
- Authorize payment with processor
- Needs: amount, customer_id, risk_score
- Async Step (awaits callback)
- Retry: 3 attempts with exponential backoff
- Runs after fraud check completes
Ledger Step (the Goal)
- Record the transaction
- Needs: transaction_id, risk_score
- Sync Step
- Must complete before responding to customer
Attribute Flow
(initial)"] Fraud["check-fraud
(risk_score)"] Auth["authorize-payment
(transaction_id)"] Ledger["record-transaction
(goal)"] Init --> Fraud Init -->|amount, customer_id| Auth Fraud -->|risk_score| Auth Fraud -->|risk_score| Ledger Auth -->|transaction_id| Ledger style Ledger fill:#c8e6c9
check-fraud runs first since it has no upstream dependencies. authorize-payment waits for risk_score, then runs while record-transaction is still pending. Once both transaction_id and risk_score are available, record-transaction runs.
Error Handling
If fraud check fails: stop Flow If authorization fails: retry, then stop If ledger fails: retry for durability
Key Points
- Fraud check prevents unnecessary authorization attempts
- Authorization is async for PCI compliance
- Recording in ledger ensures audit trail
- All Steps are idempotent for safe retries
This design ensures payment safety and compliance.