Glages: One Payment Model Across Many Business Domains
Payment is present in almost every transactional business, but it rarely exists as one isolated action. Authorization, capture, decline, retry, duplication, reversal, settlement, and refund all affect what the business can do next.
A released payment Glages Model gives these events a common formal meaning.
Payment Is a Process, Not a Provider Call
A provider API can authorize or capture money, but the API does not define the complete business process.
The payment Glages Model must identify the obligation being paid, the payer, the amount and currency, the payment method, the relevant state, and the permitted next action. It must distinguish a request to pay from an authorized payment, a captured payment, a declined attempt, and a duplicated operation.
It must also define what happens when the external service returns an uncertain or incomplete result.
Decline Is a Valid Result
A declined payment may be the correct result of a correctly executed process.
The system contacted the approved mechanism, preserved consistency, received a recognized response, and produced the modeled result Declined. Technical execution succeeded even though the requested business outcome did not occur.
This distinction matters because later processes depend on it. An order may remain unpaid. A reservation may expire. Another payment attempt may be permitted. A customer message may need to explain the result without presenting it as a system failure.
Payment Connects Domains
The same released payment Glages Model can participate in e-commerce, hospitality, insurance, healthcare, property management, repair services, marketplaces, and subscription businesses.
Each domain connects payment to different surrounding processes.
In e-commerce, payment may affect inventory reservation, shipment, and refund. In a hotel, it may affect booking confirmation, deposit, cancellation, and check-out. In repair services, it may relate to estimate approval, parts ordering, and completion.
The payment Glages Model preserves payment meaning, while Model Factory Composition can combine Glages Model assets in the Accepted or Released lifecycle state into a candidate business-domain model that defines the domain relationships.
Retry and Duplicate Protection
Payment systems often face repeated requests. A customer clicks twice, a network response is lost, or an agent retries after an uncertain outcome.
The payment Glages Model must define when retry is permitted and how a duplicate is recognized. It must distinguish a new authorized attempt from an unsafe repetition of an earlier operation.
These rules cannot be left to a general instruction such as “avoid duplicate charges.” The model must identify the relevant references, states, and evidence.
Relationship to Refund
Refund is connected to payment but remains a separate process.
The payment Glages Model establishes what was authorized, captured, declined, reversed, or settled. A separate refund Glages Model determines whether value already received may be returned and under which conditions.
Keeping the processes separate allows released process Glages Models to be reused independently while their relationship can be defined in a released business-domain Glages Model produced through Composition.
One Model, Many Interfaces
A payment may be initiated through a website, mobile application, voice interface, employee workstation, or AI chat. The interface changes how the request enters the system. It does not redefine payment.
The released payment Glages Model gives every interface the same required facts, permitted actions, Results, and stopping conditions.
This is why one released payment Glages Model can support many business domains without allowing each implementation to invent its own version of payment.