Entitlement Enforcement
Entitlement enforcement is the process of ensuring that a customer's access to a product or feature reflects the trusted state of their payment.
A payment does not automatically mean that an entitlement should be granted.
Instead, SolydFlow connects:
Transaction
↓
Truth
↓
Finality
↓
Entitlement
↓
Customer Access
This allows applications to separate payment processing from access enforcement.
Why Entitlement Enforcement Matters
Consider a customer purchasing a premium subscription.
The payment may initially be:
Payment
↓
Pending
The application should not necessarily grant premium access immediately.
The transaction may later become:
Successful
Once the required finality conditions are satisfied:
Successful
↓
Final
↓
Entitlement
↓
Premium Access
This prevents temporary or uncertain payment states from being treated as confirmed purchases.
Entitlement vs Transaction
A transaction answers:
What happened to the payment?
An entitlement answers:
What is the customer allowed to access?
They are related but different concepts.
Transaction
└── Payment was successful
Entitlement
└── Customer has access to Product X
The transaction provides the financial evidence.
The entitlement represents the resulting access.
See:
The Enforcement Flow
The simplified enforcement flow is:
Payment
↓
Transaction
↓
Truth
↓
Finality
↓
Entitlement Decision
↓
Customer Access
For a successful purchase:
Payment Successful
↓
Verified
↓
Final
↓
Grant Entitlement
↓
Access Granted
For an unresolved payment:
Payment Pending
↓
Not Final
↓
Do Not Grant Final Entitlement
Enforcement Is Based on Trusted State
An entitlement should not be granted simply because:
- A payment request was created
- A checkout was opened
- A provider was selected
- A payment attempt was made
- A provider returned an uncertain response
Instead, enforcement should be based on the transaction state established by the SolydFlow revenue infrastructure.
Provider Events
↓
Verification
↓
Truth
↓
Finality
↓
Enforcement
Successful Payment
The most straightforward case is a successfully completed transaction.
Payment
↓
Successful
↓
Verified
↓
Final
SolydFlow can then determine that the associated entitlement should become active according to the application's configuration.
Final Successful Transaction
↓
Entitlement
↓
Active
Pending Payment
A pending transaction has not necessarily reached the state required to grant access.
Payment
↓
Pending
The entitlement should therefore remain unresolved or inactive until the transaction reaches the required state.
Pending
↓
Continue Evaluation
↓
No Final Enforcement
This is particularly important for payment methods where confirmation can take time.
Failed Payment
A failed payment does not establish a successful entitlement.
Payment
↓
Failed
↓
No Successful Entitlement
If the failure is final:
Final Failure
↓
Entitlement Not Granted
If the failure is recoverable or another attempt is permitted, the transaction can continue through the applicable recovery or payment flow.
Unknown Payment Outcome
An unknown outcome requires particular care.
For example:
Payment
↓
Provider Timeout
↓
Unknown
The system should not interpret this as:
Failed
nor should it automatically grant an entitlement.
Instead:
Unknown
↓
Recovery
↓
Verification
↓
Truth
↓
Finality
↓
Enforcement
See:
Entitlement Enforcement and Finality
Finality is the boundary that allows an entitlement decision to be made safely.
Transaction State
↓
Finality
/ \
No Yes
↓ ↓
Continue Enforce
For example:
Successful
↓
Final
↓
Grant Entitlement
while:
Successful
↓
Not Yet Final
↓
Continue Evaluation
The exact finality requirements depend on the transaction and enforcement configuration.
See:
Entitlement Activation
When the transaction reaches the required successful state, the corresponding entitlement can become active.
Conceptually:
Customer
↓
Purchase
↓
Final Successful Transaction
↓
Entitlement
↓
Active
The entitlement can then be used by the application to determine what the customer can access.
Entitlement Expiration
An entitlement may have a defined validity period.
For example:
Purchase
↓
Entitlement
↓
Active
↓
Expiration
For a time-limited product:
Start
↓
Active
↓
Expiration Date
↓
Expired
The exact expiration behavior depends on the product, package, and entitlement configuration.
See:
Entitlement Renewal
A recurring or renewable entitlement may be extended by another successful transaction.
Conceptually:
Existing Entitlement
↓
Renewal Payment
↓
Verified
↓
Final
↓
Entitlement Extended
This keeps entitlement state connected to the revenue events that support it.
Entitlement and Multiple Transactions
A customer may have multiple transactions associated with an entitlement over time.
For example:
Customer
Transaction 1
↓
Initial Purchase
↓
Entitlement
Transaction 2
↓
Renewal
↓
Entitlement Extended
Transaction 3
↓
Renewal
↓
Entitlement Extended
The entitlement represents the customer's resulting access rather than treating every transaction as an independent access record.
Entitlement and Products
A transaction can be associated with a product.
Transaction
↓
Product
↓
Entitlement
For example:
Premium Product
↓
Successful Purchase
↓
Premium Entitlement
The exact relationship between products and entitlements is defined by the application's product configuration.
See:
Entitlement and Packages
Packages can define a particular commercial offering associated with a product.
For example:
Product
↓
Premium Package
↓
Purchase
↓
Entitlement
The resulting entitlement can reflect the access associated with that package.
See:
Entitlement and Pricing
Pricing determines what the customer pays.
Entitlement enforcement determines what the customer receives access to after the relevant payment outcome has been established.
Pricing
↓
Payment
↓
Transaction
↓
Finality
↓
Entitlement
These concerns should remain separate.
See:
Entitlement and Paywalls
A paywall controls when a customer must purchase access.
The entitlement determines whether that customer has already obtained the required access.
Conceptually:
Customer
↓
Paywall
↓
Does entitlement exist?
/ \
Yes No
↓ ↓
Access Purchase
After a successful purchase:
Purchase
↓
Final Transaction
↓
Entitlement
↓
Paywall
↓
Access
See:
Entitlement Enforcement and Recovery
If a payment has not reached a final outcome, SolydFlow may continue recovery.
For example:
Payment
↓
Unknown
↓
Recovery
↓
Verification
If recovery establishes success:
Successful
↓
Final
↓
Entitlement
If recovery establishes failure:
Failed
↓
Final
↓
No Successful Entitlement
This prevents entitlement decisions from being made while the payment outcome remains uncertain.
Entitlement Enforcement and Webhooks
Provider webhooks can provide important transaction evidence.
For example:
Provider
↓
Successful
↓
Webhook
↓
SolydFlow
SolydFlow can process the event as part of the transaction verification and Truth process.
Webhook
↓
Verification
↓
Truth
↓
Finality
↓
Entitlement
A webhook itself should not be confused with the entitlement.
The webhook is evidence.
The entitlement is the resulting access state.
See:
Entitlement Enforcement and Webhook Failures
A missing webhook does not necessarily mean that the transaction failed.
For example:
Provider
↓
Successful
X
Webhook Not Received
The transaction may still be recoverable through verification or reconciliation.
Missing Webhook
↓
Recovery
↓
Verification
↓
Truth
↓
Finality
↓
Entitlement
See:
Entitlement Revocation
An entitlement may need to be removed or changed when the underlying revenue state requires it.
Conceptually:
Entitlement
↓
Transaction / Revenue State Changes
↓
Truth
↓
Finality
↓
Enforcement
↓
Entitlement Updated
The exact revocation conditions depend on the product and entitlement model.
The important principle is that entitlement changes should be driven by trusted transaction information rather than by isolated provider events.
Entitlement and Refunds
A refund changes the financial outcome associated with a transaction.
Where the application's entitlement rules require it, the resulting verified state can trigger an entitlement change.
Conceptually:
Successful Purchase
↓
Entitlement Active
↓
Refund
↓
Verified State
↓
Enforcement
↓
Entitlement Updated
The exact refund and entitlement behavior depends on the supported transaction model.
Entitlement and Chargebacks
A chargeback can similarly introduce a change to the financial state of a transaction.
The general model is:
Transaction
↓
Chargeback Event
↓
Verification
↓
Truth
↓
Enforcement
↓
Entitlement Decision
The application should consume the resulting trusted entitlement state rather than implementing provider-specific chargeback handling independently.
Entitlement and Provider Failover
Failover should not grant an entitlement simply because another provider successfully received an attempt.
For example:
Provider A
↓
Unknown
↓
Recovery
↓
Failover
↓
Provider B
The entitlement should be based on the resulting transaction truth.
Provider Attempts
↓
Truth
↓
Final Transaction
↓
Entitlement
This prevents multiple provider attempts from being mistaken for multiple successful purchases.
See:
Entitlement and the Transaction Ledger
The transaction ledger provides the history behind an entitlement decision.
For example:
Transaction TX-123
Created
↓
Provider A
↓
Timeout
↓
Recovery
↓
Provider A Verified
↓
Successful
↓
Final
↓
Entitlement Granted
This history helps explain why the customer received access.
See:
Entitlement Enforcement and Multiple Providers
The customer should not need to know which provider ultimately processed the payment.
For example:
Customer
↓
SolydFlow
↓
Provider A
↓
Provider Failure
↓
Provider B
↓
Successful
↓
Entitlement
The entitlement represents the customer's access resulting from the transaction, not the provider that happened to process it.
Application Integration
The application should ideally consume the resulting entitlement rather than reconstructing it from raw provider events.
Instead of:
Provider Webhook
↓
Application
↓
Custom Payment Logic
↓
Custom Entitlement Logic
the application can work with:
Provider Events
↓
SolydFlow
↓
Truth
↓
Finality
↓
Entitlement
↓
Application
This keeps payment-provider complexity inside the revenue infrastructure layer.
Entitlement Enforcement and Security
Entitlement state should be treated as an important authorization signal.
The application should not allow a client to arbitrarily declare:
entitlement = active
Instead, entitlement state should originate from the trusted payment infrastructure.
Conceptually:
Provider Evidence
↓
SolydFlow
↓
Trusted Transaction State
↓
Entitlement
↓
Application Access
Client-side state can improve the user experience, but it should not be treated as the authoritative source for payment-derived access.
See:
Entitlement Enforcement and API Design
The application should be able to determine whether a customer has the entitlement required for a particular feature.
Conceptually:
Application
↓
Customer Entitlement
↓
Access Decision
The exact API shape depends on the SolydFlow implementation.
The important separation is:
Payment Infrastructure
↓
Entitlement State
↓
Application Authorization
Example: Successful Purchase
A customer purchases a premium package.
Payment
Customer
↓
Premium Package
↓
Payment
Transaction
Payment
↓
Successful
Truth and finality
Successful
↓
Verified
↓
Final
Enforcement
Final Successful Transaction
↓
Premium Entitlement
↓
Active
Application
Premium Entitlement
↓
Premium Features
↓
Access Granted
Example: Pending Purchase
A customer starts a purchase but the provider has not completed it.
Payment
↓
Pending
The entitlement remains unenforced:
Pending
↓
No Final Successful Transaction
↓
No Final Entitlement
When the payment eventually succeeds:
Successful
↓
Final
↓
Entitlement
↓
Access
Example: Failed Purchase
A provider definitively rejects the payment.
Payment
↓
Declined
↓
Verified Failure
↓
Final Failure
The entitlement is not activated:
Final Failure
↓
No Successful Entitlement
The customer can then be presented with an appropriate payment or retry option.
Example: Timeout With Later Success
A customer completes checkout, but the provider response times out.
Payment
↓
Timeout
SolydFlow does not immediately grant or deny access.
Unknown
↓
Recovery
The provider later confirms the transaction:
Provider
↓
Successful
Truth establishes the outcome:
Successful
↓
Final
The entitlement is then enforced:
Final Successful Transaction
↓
Entitlement Active
This allows the customer to receive the correct access without treating the original timeout as a failed payment.
Example: Failover
A payment cannot be safely completed through the initially selected provider.
Provider A
↓
Known Failure
SolydFlow evaluates another eligible provider:
Provider B
↓
Payment
↓
Successful
After verification and finality:
Provider B Success
↓
Truth
↓
Finality
↓
Entitlement
The customer receives the entitlement without needing to know which provider processed the successful payment.
The Enforcement Model
The complete Enforce flow is:
Payment
↓
Smart Routing
↓
Provider
↓
Transaction
↓
Recovery / Verification
↓
Truth
↓
Finality
↓
Entitlement Enforcement
↓
Customer Access
When something goes wrong:
Provider Problem
↓
Recovery / Truth
↓
Is the transaction final?
│
├── No
│ ↓
│ Continue evaluation
│
└── Yes
↓
Enforcement Decision
↓
Entitlement
Key Principles
1. Payment and access are separate concerns
A payment transaction records the financial event. An entitlement represents access.
2. Enforce trusted outcomes
Entitlements should be based on the trusted transaction state.
3. Do not grant access from payment attempts
Creating or attempting a payment is not equivalent to completing it.
4. Respect finality
A non-final transaction should not automatically drive a final entitlement decision.
5. Protect against duplicate payments
Multiple provider attempts should remain associated with the appropriate transaction.
6. Keep provider complexity out of the application
The application should not need to implement provider-specific entitlement logic.
7. Entitlements can change
Renewals, refunds, chargebacks, expiration, and other verified revenue events can affect entitlement state.
8. Keep enforcement traceable
An entitlement decision should be explainable through the underlying transaction history.
The Core Principle
Entitlement enforcement turns trusted payment outcomes into customer access decisions.
The complete SolydFlow model is:
Payment
↓
Provider
↓
Transaction
↓
Truth
↓
Finality
↓
Entitlement
↓
Access
This allows SolydFlow to keep the difficult payment-state logic inside the revenue infrastructure while giving applications a reliable basis for determining what customers can access.