Express Authorization

Workflow Explanation

Provides a low-latency authorization path for time-sensitive card transactions

This workflow models the express authorization leg of a card payment system, where the priority is reaching a terminal decision as quickly as possible. Rather than running the full enrichment and balance pipeline, it strips the flow down to the two checks that must clear before funds can be committed: a fraud screen and a fund reservation. A Pass state stamps metadata including an execution-scoped authorizationId and the EXPRESS channel flag before any Lambda is invoked, giving downstream states a consistent context to work with without an extra network call. The result is a realistic representation of how payment networks handle contactless payments, in-store chip transactions, and any scenario where the cardholder is waiting at a terminal and latency is measured in milliseconds.

Fraud screening gates the entire authorization path

The workflow’s first Task state invokes the fraud check Lambda and routes its output through a Choice state before allowing anything else to proceed. If the isFraudulent flag is false the execution continues; if it is true the state machine transitions immediately to a FraudBlocked Fail state with a structured FraudDetected error code. This hard-gate pattern ensures that no fund reservation is ever attempted on a transaction the model has flagged, and it makes the fraud block distinguishable from other failure modes in execution history, CloudWatch logs, and any downstream alerting system that consumes Step Functions events.

A Wait state models settlement propagation without external polling

After funds are reserved the workflow enters a Wait state named SettlementDelay rather than completing immediately. This two-second pause reflects a real characteristic of card authorization systems: once an authorization is issued, downstream settlement processors, ledger systems, and card network gateways require a short window to receive and acknowledge the reservation before the terminal state is recorded. Encoding this as a Wait state rather than a sleep inside a Lambda keeps the wait transparent in the execution graph, makes it easy to adjust the propagation window by changing a single field, and allows the state machine to remain idle without consuming Lambda compute time during the pause.

Retry and catch patterns protect against transient Lambda failures

The fraud check Task carries an exponential backoff retry policy for Lambda.ServiceException and Lambda.AWSLambdaException before escalating, and both Task states include a catch-all Catch block that routes unrecoverable failures to a distinct AuthorizationFailed Fail state. This separation matters operationally: a FraudDetected failure indicates a business-rule block, while an AuthorizationError points to an infrastructure or invocation problem. Keeping the two terminal states separate means on-call engineers can distinguish a fraud spike from a Lambda throttle event at a glance in the Step Functions console without inspecting individual execution inputs.

Complements the full pipeline and batch workflows rather than replacing them

This express path is intentionally narrower than the CreditCardTransactionProcessing workflow, which also covers validation, enrichment, and balance checks. The two are designed to coexist: the express path handles real-time point-of-sale authorizations where speed is critical and a lightweight fraud-plus-reservation check is sufficient, while the full pipeline handles higher-risk or higher-value transactions that warrant the added validation layers. Teams building on this sample can route transactions between the two paths using a Choice state in an upstream orchestrator, keying on transaction amount, channel, or merchant category code.

Simple to test end-to-end in Thrubit without any cloud deployment

Because the workflow uses only Pass, Task, Choice, Wait, Succeed, and Fail states and invokes two Lambda functions, the entire execution path can be exercised locally in Thrubit by supplying a minimal event with transactionId, amount, currency, and accountId fields. The SetRequestMeta Pass state will stamp the authorizationId and channel fields automatically, and the two-second SettlementDelay is visible as a discrete Wait step in the execution graph. Developers can test the fraud-blocked path by adjusting the fraud check Lambda to return isFraudulent: true, and test the AuthorizationFailed path by throwing from the reserve-funds handler, without touching any AWS resource or incurring costs.