Financial correctness has several layers. A journal can balance while recording the wrong amount. A valid payment request can be unauthorized. A successful payment can be missing from your application after a crash. Choosing infrastructure starts with deciding which component enforces each rule. FRAGMENT can own the financial posting boundary while Postgres owns customers, jobs, invoices and business commands. For supported customer-payment flows, FRAGMENT also offers payment execution with configured accounting. These are different capabilities with different limits.
Three architectures, three responsibility maps
| Responsibility | Protected Postgres + external payments | FRAGMENT ledger + external payments | FRAGMENT ledger + supported FRAGMENT payments |
|---|---|---|---|
| Accounting model and valid business inputs | Your team | Your team | Your team |
| Posting engine and balanced journal enforcement | Team implements and protects it | FRAGMENT applies configured ledger rules | FRAGMENT applies configured ledger rules and payment accounting |
| Ledger-write replay | Team implements stable identities and uniqueness | Use documented ledger keys; team defines business intent | Ledger keys and payment-request identities remain distinct contracts |
| Conditional balance enforcement | Team implements transactional checks and concurrency controls | Configure eligible accounts and guarded entry types | Same ledger primitive; do not assume it automatically gates every payment API |
| Payment execution | Selected provider | Selected provider | Documented FRAGMENT payment interface for supported flows |
| Payment-to-ledger mapping | Team implements | Team implements | Payment Types provide configured accounting and automatic reconciliation for supported flows |
| Operational state, approvals, unknown outcomes and exception handling | Team owns | Team owns | Team owns; determine exact service-handled transitions from payment contracts |
| Bank-statement completeness and settlement evidence | Independently establish | Independently establish | Independently establish; automatic payment accounting alone is insufficient |
The entries in the last column do not describe a general-purpose external execution runtime. They describe the documented payments product. Make Payments.
A guard must protect the write
Suppose an internal available balance is 10,000 cents. Two commands each request a 7,000-cent reservation. Reading 10,000 before each command does not stop both from proceeding. The acceptance operation must evaluate the relevant invariant as part of posting. In FRAGMENT, configure strong total-balance updates on eligible accounts and a condition on the entry type. If a postcondition requires a nonnegative balance, a competing posting that would violate it is rejected. Inspect the result and stop before external execution on an acknowledged rejection. Linked accounts cannot carry these conditions. Configure consistency. This is an illustrative acceptance rule, not deployable schema:
reserve(command):
require valid business approval and stable command identity
post reviewed reservation entry with a stable ledger-write key
atomically require relevant internal availability to remain >= 0
if rejected: record blocked; do not request payment
if acknowledgement missing: recover the same posting; do not infer success
Account scope matters. All competing commands must consume the same relevant capacity. An operation-specific pending account can track a reservation, but independent pending accounts do not by themselves enforce a shared refund ceiling. For financial decisions, explicitly request strong reads on appropriately configured accounts; that read still does not replace a guarded write.
Replay is narrower than business uniqueness
Reusing the valid ledger-write key for the same intended posting supports retrying that write. It does not recognize that two different commands or keys refer to the same invoice payment. Enforce business-intent uniqueness separately, and verify payment-request replay semantics separately. Post Ledger Entries.
What remains outside the guarantee
A correct schema does not prove that an invoice is genuine, an amount is appropriate, a saved-card charge is authorized or a refund is warranted. Restrict credentials, validate commands, bind approvals to immutable details and review schema changes. Preserve uncertain execution states until canonical evidence resolves them.
For supported FRAGMENT payments, automatic payment-to-ledger reconciliation reduces the mapping your application must maintain between those payments and their configured accounting. It does not establish that all inbox, lookup, retry, recovery or independent reconciliation work disappears. Map native accounting before adding manual entries; posting the same economic movement through both paths can double count it.
Decide on ownership
Use FRAGMENT when delegating configured financial enforcement and supported accounting flows justifies another service and its integration responsibilities. A protected Postgres ledger can be appropriate when your team can own and review the posting engine and values local atomicity. Neither architecture makes unreviewed financial business logic correct.
Implementation references
Use the current API contracts when implementing the architecture: