https://stackonward.com/tags/saas/Recent content in SaaS on StackOnwardHugoen-USFri, 11 Sep 2026 12:00:00 +0800https://stackonward.com/posts/payment-attempt-transaction-separation/Fri, 11 Sep 2026 05:22:00 +0800https://stackonward.com/posts/payment-attempt-transaction-separation/<p>Payment, Attempt, and Transaction amounts cannot be added together. Payment stores owner and target amount for one local collection. Attempt stores the conditions and progress of one accepted operation. Transaction stores the result of one channel money action. A failed try followed by a succeeded retry can leave two execution records and only one amount received.</p> <p>Keeping only the latest state on one row lets a retry overwrite the last failure, lets a refunded net hide the original capture, and leaves a back-office “success” that cannot say whether money was captured. Separate records answer how many times the customer tried, how much the channel actually captured, and how much was later returned.</p>https://stackonward.com/posts/payment-domain-object-model/Fri, 11 Sep 2026 05:20:00 +0800https://stackonward.com/posts/payment-domain-object-model/<p>A purchase can capture successfully while the workspace stays “provisioning.” Charging again does not fix that. Find the fulfillment record for the original order, and why it did not finish.</p> <p>A payment domain model stores sale terms, execution, and money results as separate identities. Quote freezes the payable amount. Order stores what both sides confirmed. CheckoutSession and execution records manage the collection process. Payment is the local payment. Transaction stores the result of a specific money action. Provider objects attach through their own identity map. Refunds and fulfillment then point at confirmed purchase and money records. One <code>paid</code> field cannot replace those links.</p>