A cross-border platform has several kinds of variation. A customer’s market affects payment and pricing units. A sales channel affects business pricing and available workflows. The person placing an order may also be different from the account paying for it.
I model these responsibilities separately. This makes a new business rule easier to place and gives each transaction a clear context.
Keep the dimensions explicit
| Dimension | Question it answers |
|---|---|
| Market | Which pricing unit and payment policy apply to this account? |
| Channel | Which catalog, pricing and purchasing workflow apply? |
| Account relationship | Who may act, whose funds are used, and what limit applies? |
These policies are loaded by the server. A domain name or a browser-selected currency is not authoritative evidence of an account’s market.
The storefront shares pages and business modules across retail and B2B. Channel policy enables the supported operations, while market policy supplies the relevant amount and payment settings. A channel can still restrict which markets it supports; separate dimensions do not imply that every combination is valid.
Carry the context into the transaction
Displaying the correct currency is only the first step. Payment, refund, cancellation and adjustment must all resolve the same account, channel and unit.
An order therefore preserves the context used to price and pay for it. A later refund follows that order’s billing responsibility, rather than inferring a destination from the customer’s current screen or whichever balance record a query finds first.
For B2B purchasing, I distinguish the acting user from the billing account. The server verifies the relationship, checks the purchasing limit, and records the actor alongside the financial movement. This supports shared billing without losing accountability for individual purchases.
Shared identity does not imply shared access
The platform’s storefront, administration, staff workspace and customer portal share accounts. Access to one application does not automatically authorize another. Entry checks, operation permissions and database grants answer different questions and are enforced separately.
This distinction is especially useful when a person has more than one role. The account identifies the person; the requested operation and its data scope determine what they may do.
What I verify
Tests exercise unit selection, billing ownership and access denial. Reconciliation also checks that financial entries agree with the account, channel and unit of the balance they affect.
The model is doing useful work when the same rule holds at checkout, on a refund, in an operator’s action and in a background job. Those are the places where an implicit assumption otherwise becomes a different answer.