A payment looks like one operation until your application has to implement it again in the books.
The processor records what happened to the money. Your application has to record what that means for the business: what the customer paid, what service is still owed, what fee was taken, and what obligation remains after a refund.
And because these records live in different systems, something has to connect them. A settlement becomes a journal entry. A processing fee becomes an expense. A refund changes the payment account and the obligation to the customer. The connector has to find the right booking, apply the right transition, and recover a missed posting without moving money again.
That work can live in your application or in an existing integration. Either way, somebody supplies and operates it.
But payment execution and payment accounting can be designed together.
With FRAGMENT, a Payment Type defines the accounting associated with the native payment lifecycle. Settlement, fees, refund initiation and refund failure have configured entries. Your application uses FRAGMENT's payment and refund interface; the supported lifecycle generates its accounting in the FRAGMENT ledger.
The distinction matters. A FRAGMENT ledger fed by direct Stripe calls still needs an integration between Stripe's records and that ledger. Native FRAGMENT payments delegate the supported payment-to-ledger mapping along with the posting engine.
And that leaves the application with the decisions only it can make.
A customer paying for a workshop does not tell you whether the workshop has been delivered. A refund does not tell you which cancellation policy applies. Those decisions need explicit business entries: move an unearned obligation to revenue when service is delivered, or recognize a refund obligation when a cancellation is approved.
The application chooses the business transition. The Payment Type accounts for the supported payment transition.
Those responsibilities meet in the same financial model. Principal, fees, unearned obligations, earned revenue and refund obligations can be explained together without hand-posting a second settlement or refund entry after the native flow has already recorded it.
Payouts stay in the same ledger
FRAGMENT records a payout to the merchant’s bank automatically as an entry moving funds out of the payments account. The application does not build a separate payout-to-ledger mapping.
And when the merchant’s bank account is linked in FRAGMENT, the deposit reconciles automatically too. The application does not write the code to match that deposit to the payout.
Choose who owns the accounting
There is still a real architecture choice. A protected journal inside Postgres can commit a booking update, a financial entry and an outbox record in one local transaction. A remote ledger requires coordination with that local state. Neither arrangement makes the card network part of the database transaction.
The choice is who owns the posting engine and the payment-to-journal integration. If you already have both, account for what they do. If you have neither, count them among the things your team would otherwise build.
From collection through a refund, a payment already has a lifecycle. Its accounting should be part of it.