Skip to main content
PATCH
Change Transaction Status

Endpoint

Change Transaction Status

Updates the status of an existing transaction with automatic validation of state transitions and optional rule execution for real-time risk re-assessment. Features:
  • Automatic validation of status transitions (prevents invalid state changes)
  • State machine enforcement (open ↔ closed state rules)
  • Automatic execution of rules/matrices with transaction_status_changed trigger (not transaction_updated)
  • Transaction integrity protection
  • Comprehensive audit trail

Authentication

All requests must include an API key in the Authorization header:

Required Headers

Path Parameters

string
required
The UUID of the transaction to updateType: string (uuid)

Request Body

string
required
New transaction status. Must be a valid status enum value.Valid Statuses:
  • CREATED - Transaction created (open state)
  • PROCESSING - Transaction being processed (open state)
  • SUSPENDED - Transaction temporarily suspended (open state)
  • SENT - Transaction sent/transmitted (closed state)
  • EXPIRED - Transaction expired (closed state)
  • DECLINED - Transaction declined/rejected (closed state)
  • REFUNDED - Transaction refunded/reversed (closed state)
  • SUCCESSFUL - Transaction completed successfully (closed state)
Type: enum - 'CREATED' | 'PROCESSING' | 'SUSPENDED' | 'SENT' | 'EXPIRED' | 'DECLINED' | 'REFUNDED' | 'SUCCESSFUL'

State Transition Rules

The endpoint enforces strict state transition rules to maintain transaction integrity:

Open States

States that allow further transitions:
  • CREATED
  • PROCESSING
  • SUSPENDED
  • SENT

Closed States

Final states that cannot transition to other states:
  • EXPIRED
  • DECLINED
  • REFUNDED
  • SUCCESSFUL

Transition Matrix

Key Rules:
  1. βœ… Open β†’ Open: Allowed (e.g., CREATED β†’ PROCESSING)
  2. βœ… Open β†’ Closed: Allowed (e.g., PROCESSING β†’ SUCCESSFUL)
  3. ❌ Closed β†’ Open: NOT Allowed (e.g., SUCCESSFUL β†’ PROCESSING)
  4. ❌ Closed β†’ Closed: NOT Allowed (e.g., DECLINED β†’ REFUNDED)

Update Rules Execution

When a transaction status is changed, the endpoint automatically:
  1. Validates the transition - Ensures the new status is valid and transition is allowed
  2. Updates the status - Changes the transaction status in the database
  3. Executes status-change rules - Runs rules/matrices with trigger status_changed (scope action or matrix transaction_status_changed)
  4. Updates risk score - Re-calculates risk based on rule results
  5. Returns updated transaction - Returns the complete transaction with new risk assessment
Distinct from field updates: PATCH /transactions/{id} (metadata, deviceDetails, channel, reason) uses trigger updated. Only this changeStatus endpoint uses status_changed. Migrate rules that should run on status transitions to the new trigger.

Rules Trigger

The endpoint uses trigger_transaction_status_changed, which executes rules configured with:
  • Loose rules: scope.triggers[].event.action = "status_changed"
  • Risk matrices: triggers[].eventType = "transaction_status_changed"
Example rule scope configuration:

Complete Request Examples

Approve a Suspended Transaction

Decline a Transaction Under Review

Suspend a Transaction for Manual Review

Response

Success Response (200 OK)

Response Fields

boolean
Whether the status change was successful
object
The updated transaction with all its data, including:
  • id (string) - Transaction UUID
  • status (string) - New transaction status
  • origin (object) - Origin party information (nested structure)
    • entityId (string) - Origin entity UUID
    • name (string) - Origin party name
    • country (string) - Origin country
    • details (object) - Additional origin details
    • type (string) - Origin entity type
    • riskScore (number) - Origin entity risk score
  • destination (object) - Destination party information (nested structure)
    • entityId (string) - Destination entity UUID
    • name (string) - Destination party name
    • country (string) - Destination country
    • details (object) - Additional destination details
    • type (string) - Destination entity type
    • riskScore (number) - Destination entity risk score
  • riskScore (number) - Updated risk score after re-evaluation
  • riskFactors (array) - Updated risk factors
  • flagged (boolean) - Updated flag status
  • updatedAt (string) - Timestamp of the update
object
Information about the status transition:
  • from (string) - Previous status
  • to (string) - New status
object
At the root of the response (aligned with Create transaction). Only present when rules ran. Summary of which rules matched (hit) vs did not match (no hit), executed actions, and total score.
  • rulesHit (array) - Rules whose conditions were met. Each item: name, description, score, priority, category, status, conditions, actions.
  • rulesNoHit (array) - Rules evaluated but conditions not met. Same structure as rulesHit.
  • actionsExecuted (object) - Aggregated executed actions: alerts, suggestion, status, assignedUser, customKeys (array of strings, optional) β€” custom action keys from rules that matched; for integrations/workflows.
  • totalScore (number) - Sum of score of all rules that hit (excluding shadow).

Error Responses

400 Bad Request - Invalid Status

400 Bad Request - Invalid Transition

404 Not Found

401 Unauthorized

500 Internal Server Error

Use Cases

1. Manual Review Workflow

2. Automated Compliance Check

3. Fraud Detection Response

4. Bulk Status Updates

Best Practices

  1. Validate before changing - Always check the current status before attempting a status change to avoid unnecessary API calls
  2. Handle transition errors - Implement proper error handling for invalid transitions, as closed transactions cannot be reopened
  3. Use appropriate statuses - Choose the correct status that reflects the actual business state of the transaction
  4. Monitor rule execution - Pay attention to rulesExecutionSummary to ensure update rules are triggering as expected and check execution details, warnings, and metadata
  5. Implement audit logging - Track all status changes in your system for compliance and debugging purposes
  6. Bulk updates - When updating multiple transactions, use Promise.allSettled() to continue processing even if some updates fail
  7. Webhook integration - Consider setting up webhooks to receive notifications when status changes trigger important rules
  8. Testing state transitions - Test all possible state transitions in your development environment before deploying to production

Create Transaction

Create new transactions

Get Transaction

Retrieve transaction details

Rules Configuration

Configure update rules

Overview

Back to overview