Payments, billing, and subscriptions on StackOnward

Go Live with Payments: From Sandbox Keys to the First Real Order

Fri, 11 Sep 2026 05:24:00 +0800

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.

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.

Why Payment, Attempt, and Transaction Must Stay Separate

Fri, 11 Sep 2026 05:22:00 +0800

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.

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.

Payment Domain Model: Order, Payment, Attempt, and Transaction

Fri, 11 Sep 2026 05:20:00 +0800

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.

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 paid field cannot replace those links.

Why Payment Methods Are Not Showing at Checkout

Fri, 11 Sep 2026 05:08:00 +0800

RouteNest’s Pro monthly checkout produced three results. A Dutch buyer paying in EUR on desktop saw iDEAL and cards. A US buyer paying in USD saw cards plus Apple Pay or Google Pay. The same US buyer opening the page from a limited in-app WebView lost the wallet buttons. Why payment methods not showing at checkout for one customer, while another still sees them: each method has to pass the current account, this order, the buyer’s device, and this page’s settings. Change one of those, and the list can change.

Hosted Checkout vs Embedded Checkout

Fri, 11 Sep 2026 05:00:00 +0800

RouteNest put the Pro payment form on the pricing page. A Dutch buyer chose iDEAL, and the browser still left for the bank. After the buyer authorized and came back, membership did not turn on, because the payment webhook had not arrived. Nothing was broken: where the form lives, whether the payment leaves the page, and whether payment is confirmed are three different jobs.

If the provider’s full checkout page already covers the required payment methods and fields, start with hosted checkout. Keep a hosted embedded form only when the product configuration before payment cannot be abandoned. Split into hosted components when a prebuilt form cannot hold seats, add-ons, or a live quote. Generating the card number field in your own page jumps the security and compliance work; that is usually the wrong starting point for SaaS.

Merchant of Record vs Payment Processor: Who Sells the Order

Fri, 11 Sep 2026 05:00:00 +0800

A customer buys a pretax $100 SaaS annual subscription and pays $20 more in tax. Both setups can mark the order paid. Direct payment processing still has your company selling to the customer and carrying tax, refunds, and delivery. A merchant of record (MoR) becomes the seller the buyer faces on in-scope orders, then pays you a supplier amount after tax, fees, and contract adjustments.

That is the merchant of record vs payment processor difference that matters. A payment processor answers how authorization, capture, and settlement complete. An MoR also changes who sold the product to the buyer. Hosted versus embedded checkout, whose API you call, and which balance first held the funds cannot prove seller identity on their own.

How to Model SaaS Products, Plans, and Prices

Fri, 11 Sep 2026 04:18:00 +0800

RouteNest is about to raise Pro monthly from $19 to $24. If the system stores one mutable row—plan=pro, price=19, stripe_price_id=...—writing 24 over 19 removes the basis for existing subscriptions. Whether the $190 annual price moves, whether the euro price is recomputed, which amount WELCOME20 discounts, and which Paddle or Creem object to charge all become guesses.

How to model SaaS products and prices depends on when each fact changes. Product says what is sold. Plan says which features and limits the buyer receives. Price says amount, currency, interval, and version. A promotion only changes a qualifying sale. A provider mapping only projects an internal Price onto a payment channel. Orders and subscriptions must store the snapshot from the sale; they cannot reread “the current price” to explain the past.

Why a Payment Processor Application Gets Rejected, and How to Resubmit Evidence

Fri, 11 Sep 2026 04:16:00 +0800

A payment processor application is rejected when a reviewer cannot independently match who is selling, through which domain, what the buyer receives after payment, who handles cancellation or refunds, and who receives the net proceeds. Genuine files still fail when those facts point at different businesses.

The application names Northstar Labs, Inc.. The site footer only shows the product name RouteNest. The pricing page sells a USD 19 monthly auto-renewing subscription, while the refund page still describes a one-time download. The product is behind login and the reviewer has no account. The payout account still names the founder personally. Each of those statements can be true. Together they do not say who sells what, how it is delivered, or where the money goes.