Transaction Finality
Transaction finality defines when a payment transaction has reached a state that SolydFlow can safely treat as settled for a particular decision.
A payment can move through several states before its outcome becomes clear:
Created
↓
Pending
↓
Processing
↓
Successful
But reaching a provider-reported state is not always enough to determine whether SolydFlow should:
- Grant an entitlement
- Stop retrying
- Stop recovery
- Prevent another payment attempt
- Allow provider failover
- Treat the transaction as complete
Finality provides the boundary between an outcome that may still change and an outcome that can safely drive enforcement.
Why Finality Matters
Consider a payment that is currently pending:
Payment
↓
Pending
The payment may eventually become:
Successful
or:
Failed
If the application treats Pending as final, it could make an incorrect decision.
For example:
Pending
↓
Grant Premium Access
The customer could receive access before the payment is actually established as successful.
Finality helps prevent this kind of premature enforcement.
Finality and Transaction State
Transaction state describes where the transaction currently is.
Finality describes whether that state is sufficiently established for the decision being made.
Conceptually:
Transaction State
↓
Is the state final?
/ \
No Yes
↓ ↓
Continue Enforce
evaluation
This means that state and finality should not be treated as the same concept.
See:
A Transaction Can Be Non-Final
A transaction can have a known state while still being subject to change.
For example:
Transaction
└── Pending
The state is known:
Pending
But the final outcome is not yet established.
Pending
↓
?
It may later become:
Successful
or:
Failed
Therefore, a non-final state should not automatically trigger actions that require a final outcome.
Finality and Successful Transactions
A successful transaction may eventually become final for the relevant enforcement decision.
Conceptually:
Provider
↓
Successful
↓
Verification
↓
Final
Once the transaction has reached the required finality condition:
Final
↓
Entitlement Enforcement
The application can use the resulting transaction outcome with greater confidence.
The exact definition of finality depends on the transaction model and provider behavior supported by SolydFlow.
Finality and Failed Transactions
Finality is not limited to successful transactions.
A transaction can also reach a final failed outcome.
For example:
Payment
↓
Declined
↓
Verified
↓
Final Failure
A final failure may allow SolydFlow to stop recovery or determine that another eligible payment attempt can be considered.
Conceptually:
Final Failure
↓
No Successful Entitlement
Whether a new attempt is permitted depends on the transaction and retry/failover rules.
Finality and Unknown Outcomes
An unknown outcome should not normally be treated as final.
For example:
Payment Request
↓
Timeout
↓
Unknown
The system does not yet know whether the provider completed the transaction.
Therefore:
Unknown
↓
Recovery
↓
Verification
↓
Truth
The transaction should remain unresolved until sufficient evidence exists to establish its state.
See:
Finality and Truth
Truth determines the transaction state that can be relied upon from the available evidence.
Finality builds on that result.
Provider Evidence
↓
Verification
↓
Truth
↓
Transaction State
↓
Finality
For example:
Provider A → Successful
Provider B → Successful
Ledger → Successful
↓
Truth
↓
Successful
↓
Final
The exact evidence and consensus rules are handled by the Truth layer.
See:
Finality and Provider Failover
Finality is particularly important when deciding whether another provider should process a payment.
Consider:
Provider A
↓
Timeout
The transaction is not necessarily failed.
Therefore:
Timeout
↓
Not Final
↓
Do Not Blindly Fail Over
Instead:
Timeout
↓
Recovery / Verification
↓
Truth
↓
Final State
↓
Failover Decision
This helps prevent duplicate payments.
See:
Finality and Smart Routing
Smart Routing selects the initial provider.
Finality helps determine when the resulting transaction should no longer be treated as an opportunity for another payment attempt.
For example:
Smart Routing
↓
Provider A
↓
Payment
↓
Successful
↓
Final
Once the transaction has reached the required final state, routing should not create another payment attempt for the same transaction.
See:
Finality and Recovery
Recovery deals with transactions whose outcomes need further investigation.
For example:
Pending
↓
Recovery
↓
Verification
↓
Successful
The transaction can then move toward finality.
Successful
↓
Final
If recovery instead establishes a failure:
Pending
↓
Recovery
↓
Failed
↓
Final Failure
Finality allows the recovery process to know when further investigation is no longer necessary for that outcome.
Finality and Webhooks
Webhooks are an important source of transaction evidence, but webhook delivery itself does not necessarily define finality.
For example:
Provider
↓
Successful
↓
Webhook
SolydFlow can process the webhook and evaluate the transaction through the appropriate verification and Truth processes.
Webhook
↓
Verification
↓
Truth
↓
Finality
A missing webhook also does not necessarily mean the transaction failed.
Payment
↓
Webhook Missing
↓
Recovery / Verification
↓
Truth
See:
Finality and Entitlements
Entitlements represent what a customer is allowed to access.
A transaction should not grant a final entitlement merely because a payment attempt occurred.
For example:
Payment Attempt
↓
Pending
↓
No Final Entitlement
Once the transaction reaches the required final successful state:
Successful
↓
Final
↓
Entitlement
↓
Active
This creates a clear relationship between trusted revenue state and customer access.
See:
Finality and Entitlement Revocation
Finality can also matter when a transaction changes in a way that affects an existing entitlement.
For example:
Active Entitlement
↓
Transaction State Changes
↓
Verified Final Outcome
↓
Enforcement Decision
The application should not assume that every transaction state change immediately requires the same access decision.
The relevant final state should determine the enforcement action.
Finality and Duplicate Prevention
One of the most important uses of finality is preventing multiple payment attempts from being treated as independent purchases.
Consider:
Transaction TX-123
↓
Provider A
↓
Timeout
If the transaction is still unresolved:
TX-123
└── Unknown
SolydFlow should investigate the transaction rather than automatically creating another successful purchase.
Once the outcome becomes final:
TX-123
└── Successful / Final
The system knows that another payment attempt should not be treated as a separate completion of the same transaction.
Finality and Transaction Identity
Finality applies to the transaction being evaluated, not merely to an individual provider response.
Consider:
Transaction TX-123
│
├── Provider A Attempt
│
└── Provider B Attempt
The transaction can contain multiple provider attempts while still representing one application payment operation.
The final transaction outcome should therefore be determined from the complete transaction evidence rather than from one isolated provider response.
Finality and Provider Attempts
A provider attempt may have its own outcome:
Provider A
└── Timeout
while the overall transaction remains unresolved:
Transaction
└── Unknown
Later:
Provider A
└── Successful Webhook
The transaction can then be evaluated again:
Transaction
└── Successful
└── Final
This is why provider-attempt status and transaction finality should not be treated as interchangeable.
Finality and Reconciliation
Reconciliation can provide evidence that helps resolve a transaction.
For example:
SolydFlow
└── Pending
Provider
└── Successful
Reconciliation may identify the discrepancy.
Reconciliation
↓
Evidence
↓
Truth
↓
Successful
↓
Final
See:
Finality and the Transaction Ledger
The transaction ledger provides a history of transaction activity.
For example:
Transaction TX-123
Created
↓
Pending
↓
Provider Timeout
↓
Verification
↓
Successful
↓
Final
This history helps explain why SolydFlow reached a particular final state.
See:
Finality Is Contextual
A transaction does not necessarily have one universal concept of finality for every possible operation.
For example, a state may be sufficient to:
Stop a retry
while another decision may require stronger confirmation before:
Granting an entitlement
Therefore, documentation and implementation should distinguish between:
- Transaction state
- Evidence
- Finality requirements
- Enforcement decision
The exact finality rules depend on the SolydFlow transaction model and the operation being performed.
Finality Does Not Mean Immutability
Finality should not automatically be interpreted as meaning that a record can never change under any circumstances.
Instead, it means that the transaction has reached the required state for a particular system decision.
For example:
Final for payment enforcement
does not necessarily mean:
Impossible for any later provider event to exist
A later event may still need to be recorded, investigated, or reconciled.
The important distinction is between:
Final for a decision
and:
Historically impossible to receive new information
These are not necessarily the same thing.
Finality and State Changes
A transaction may move through several states:
Created
↓
Pending
↓
Processing
↓
Successful
The system should evaluate each transition according to the rules for that transaction.
For example:
Pending
↓
Successful
↓
Finality Evaluation
↓
Enforcement
The finality evaluation is what determines whether the new state can drive the relevant downstream action.
Finality Decision Flow
A simplified model is:
Transaction State
↓
Evidence Available?
/ \
No Yes
↓ ↓
Recover Truth
↓
Reliable State
↓
Finality Check
↓
┌──────┴──────┐
↓ ↓
Non-Final Final
↓ ↓
Continue Enforce
Evaluation
Finality and Application Integration
The application should not need to reconstruct finality from raw provider responses.
Instead, it should consume the transaction state and enforcement result exposed by SolydFlow.
Conceptually:
Payment Infrastructure
↓
SolydFlow
↓
Transaction State
↓
Finality
↓
Application
This reduces provider-specific payment logic inside the application.
Finality and Production Operations
When investigating a transaction, operators should be able to distinguish:
Current State
from:
Final State
For example:
Current:
Pending
Final:
Not established
versus:
Current:
Successful
Final:
Established
This distinction makes operational debugging much clearer.
Example: Pending Transaction
A customer starts a payment:
Customer
↓
Payment
↓
Provider
↓
Pending
SolydFlow should not immediately assume:
Successful
Instead:
Pending
↓
Monitor / Recover
↓
Verify
↓
Truth
If the provider eventually confirms success:
Successful
↓
Final
↓
Entitlement
Example: Timeout
A payment request times out:
Application
↓
Provider
↓
Timeout
The outcome is unknown:
Unknown
SolydFlow investigates:
Recovery
↓
Provider Verification
↓
Truth
If the provider did not process the payment:
Failed
↓
Final Failure
A safe retry or failover may then be considered according to the applicable rules.
Example: Successful Payment
A provider reports success:
Provider
↓
Successful
SolydFlow evaluates the available evidence:
Successful
↓
Truth
↓
Finality
Once finality is established for entitlement enforcement:
Final
↓
Entitlement Enforcement
↓
Access Granted
Example: Provider Failure
A provider becomes unavailable before processing begins:
Provider A
└── Unavailable
Because the payment has not been attempted through Provider A:
No Uncertain Transaction
SolydFlow can evaluate another eligible provider:
Provider B
↓
Payment
This is different from failing over after an uncertain payment attempt.
Example: Provider Success After Timeout
A payment times out:
Provider A
↓
Timeout
Recovery begins:
Timeout
↓
Recovery
Later, the provider sends confirmation:
Provider A
↓
Successful Webhook
Truth establishes:
Successful
Finality is then evaluated:
Successful
↓
Final
The transaction should not be failed over merely because its original response was delayed.
Finality and Enforce
The relationship between finality and Enforce is:
Truth
↓
Reliable Transaction State
↓
Finality
↓
Enforce
Enforce can then apply the appropriate action:
Final Successful
↓
Entitlement
Final Failure
↓
No Successful Entitlement
Non-Final
↓
Continue Evaluation
The exact enforcement behavior depends on the transaction and entitlement configuration.
Key Principles
1. State is not automatically final
A transaction can have a known state while still being unresolved for an enforcement decision.
2. Unknown is not failure
A timeout or missing response may represent an unknown outcome.
3. Truth precedes finality
Finality should be evaluated using the transaction state established from appropriate evidence.
4. Finality protects against duplicate payments
An unresolved transaction should not automatically generate another payment attempt.
5. Finality protects entitlements
Customer access should be based on the appropriate final transaction outcome.
6. Finality supports failover
Provider switching should account for whether the original transaction is still unresolved or has reached a final outcome.
7. Finality is decision-oriented
A transaction being final for one operation does not necessarily mean that no later evidence can ever exist.
8. Preserve the transaction history
Finality decisions should remain traceable through the transaction record and ledger.
The Core Principle
Finality is the point at which a transaction state is sufficiently established to safely drive the decision being made.
The simplified flow is:
Provider Evidence
↓
Truth
↓
Transaction State
↓
Finality
↓
Enforce
↓
Application / Entitlement
This allows SolydFlow to make revenue and access decisions without treating every intermediate payment state as a completed outcome.