<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Webhook on StackOnward</title><link>https://stackonward.com/tags/webhook/</link><description>Recent content in Webhook 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/webhook/index.xml" rel="self" type="application/rss+xml"/><item><title>Go Live with Payments: From Sandbox Keys to the First Real Order</title><link>https://stackonward.com/posts/payment-sandbox-to-production-launch/</link><pubDate>Fri, 11 Sep 2026 05:24:00 +0800</pubDate><guid>https://stackonward.com/posts/payment-sandbox-to-production-launch/</guid><description>&lt;p&gt;The checkout page already uses a live key, but the subscription still cites a test Price. After the customer pays, the production webhook fails signature checks because it still uses the sandbox secret. Mixed config does not fail together: some errors stop before payment, others wait until money has moved, then order, entitlements, and finance stop in different states.&lt;/p&gt;
&lt;p&gt;The cutover order is: fence entries that create captures and refunds; attach account, keys, Price, webhook, domain, workers, and finance to live together; use read-only requests, test events, and return-URL checks to catch environment errors; then open the first real order under provider rules. If that first order fails, close new transactions. Webhooks, lookups, and reconciliation keep running.&lt;/p&gt;</description></item><item><title>Payment Domain Model: Order, Payment, Attempt, and Transaction</title><link>https://stackonward.com/posts/payment-domain-object-model/</link><pubDate>Fri, 11 Sep 2026 05:20:00 +0800</pubDate><guid>https://stackonward.com/posts/payment-domain-object-model/</guid><description>&lt;p&gt;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.&lt;/p&gt;
&lt;p&gt;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 &lt;code&gt;paid&lt;/code&gt; field cannot replace those links.&lt;/p&gt;</description></item></channel></rss>