<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Partial Refund on StackOnward</title><link>https://stackonward.com/tags/partial-refund/</link><description>Recent content in Partial Refund on StackOnward</description><generator>Hugo</generator><language>en-US</language><lastBuildDate>Fri, 11 Sep 2026 12:00:00 +0800</lastBuildDate><atom:link href="https://stackonward.com/tags/partial-refund/index.xml" rel="self" type="application/rss+xml"/><item><title>Why Payment, Attempt, and Transaction Must Stay Separate</title><link>https://stackonward.com/posts/payment-attempt-transaction-separation/</link><pubDate>Fri, 11 Sep 2026 05:22:00 +0800</pubDate><guid>https://stackonward.com/posts/payment-attempt-transaction-separation/</guid><description>&lt;p&gt;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.&lt;/p&gt;
&lt;p&gt;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.&lt;/p&gt;</description></item></channel></rss>