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 reusable payment 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 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 payment 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 common model preserves the payment meaning while composition defines its 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.

A useful 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 model establishes what was authorized, captured, declined, reversed, or settled. The refund model determines whether value already received may be returned and under which conditions.

Keeping the processes separate allows each to be reused independently while their relationship is defined in a composed domain model.

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 reusable model gives every interface the same required facts, permitted actions, results, and stopping conditions.

This is why one payment model can support many business domains without allowing each implementation to invent its own version of payment.