Theme
Payments and money
Where card payments, receipts and prices go wrong between the gateway and your own records.
22 posts by DX, in two lanes: plain-language stories and the technical build log.
Everyday lane
Plain-language stories. No jargon. 7 posts.
Start here
Thirteen Hours Lost to a Payment Receipt and the Wrong Number
A payment receipt was using the payment service's number instead of the order's number, so we put up a temporary public page to see the real message and fix it.
Card payment integrations that fail quietly
-
Why Every Receipt Failed to Find the Registrant
A small mix-up between two payment numbers showed why the right label matters more than a clever fallback.
-
We Fixed the Wrong Registration Bug and Found a Public Door
A receipt problem led to a further discovery: a public payment page was accepting whatever data arrived at its door.
-
Thirteen Hours Lost to a Payment Receipt and the Wrong Number
A payment receipt was using the payment service's number instead of the order's number, so we put up a temporary public page to see the real message and fix it.
-
Three Fixes on April 21 and Each One Was Called Done Too Early
For a while, payments arrived while registration records said they had not.
Prices and currencies at PayPal checkout
Pricing, bundles and checkout totals
-
One Plan Label, Three Items, and a 10-Entry Customer Paying for 200
A pricing label hid three separate purchases, so we had to separate everyday access from a one-weekend event.
-
What a ?prototype=1 Flag Could Not Protect in Our Checkout
A late-night redesign showed why a new screen is not ready until the money underneath it still adds up.
Technical lane
The build log: the logs, the code, the fix. 15 posts.
Start here
x_trans_id vs x_invoice_num in an Authorize.Net Direct Post Receipt
An OR fallback treated x_trans_id and x_invoice_num as the same identifier, so every prod receipt failed while tests passed. The fix was deleting half a line.
Card payment integrations that fail quietly
-
x_trans_id vs x_invoice_num in an Authorize.Net Direct Post Receipt
An OR fallback treated x_trans_id and x_invoice_num as the same identifier, so every prod receipt failed while tests passed. The fix was deleting half a line.
-
Why x_trans_id or x_invoice_num Broke Every Receipt Page in Production
Stripe expects your landing page to capture the charge; Authorize.Net DPM settled before the redirect. Copying one handler for the other fails silently in prod.
-
What a disposable relay page in production showed us about x_trans_id
When a gateway won't POST to localhost, ship a throwaway relay page to prod and read the real payload. Three bugs surfaced that a faked callback never would.
-
A Trusted Gateway POST Is Still a Public Endpoint
A payment gateway callback fed a raw POST field straight into a SQL WHERE clause. How trusted-caller framing kills input validation, plus the five-line boundary fix.
-
The Webhook Posts That Stopped Reaching Our Handler in Late May
At 2:07 PM on June 22, we fixed a payment that had been charged but had never reached the account that paid it. The customer had done their part. Our recurring-payment integration had not.
-
The Whole Feature Was Built and Verified in Sandbox, Then Prod Said E00044: CIM Not Enabled
A tokenization feature passed every sandbox test, then production returned E00044: CIM not enabled. Probe the vendor capability in prod before you build.
-
The Objection That Kept a Billing Bug Alive Was Never Checked
A client's plan offer expired after 23 hours because it only existed as an unpaid Stripe subscription. The fix we had skipped rested on an objection nobody had checked.
-
A Paid Charge Row Sat in client_charges While the Page Showed Zero
The payment cleared at 18:16:03 UTC. Stripe fired paymentintent.succeeded, invoice.paymentsucceeded, checkout.session.completed, all three, on schedule.
-
A Silent Renewal Failure and the Safeguard Behind It
A silent failure got fixed by removing a safeguard entirely. Before it ever shipped, that turned out to be the wrong fix.
-
The Bug That Would Fail Every First Win-Back Conversion
At 1:20 PM we shipped the win-back flow to our review branch: a mailer link that lets someone whose trial expired sign back in and convert the site to a paid account in the same motion.
Prices and currencies at PayPal checkout
-
The CAD Multiplier Shipped at 1.4 and Changed to 1.31 the Next Day
Adding CAD checkout to a single-currency database: translate only at the view and the gateway, and never let the gateway's rounded amount write back over your stored total.
-
One Unlabeled Figure in dbo.transactions and a CAD Email
A CAD customer paying a USD invoice exposed the classic accounting bug: the system stored the merchant currency and lost the buyer's actual money story.
-
The 300ms timeout that fixed a stale financing estimate
A checkout total updated after a coupon, but its Pay Later message retained the old amount. Replacing the SDK-owned DOM node and scheduling a fresh render resolved the stale estimate.
Pricing, bundles and checkout totals
-
Why a 47-Line Architecture Doc Outlived Our Pricing Prototype
An event-pricing prototype looked simple until it met hybrid checkout, existing feature gates, proration, account-state rules, and legacy billing. The hard part was making the product decisions explicit across those systems.
-
Why a Custom Domain Cost the Same as 200-Group Capacity
A two-layer event-pricing redesign separated recurring platform access from one-time event capacity, then used membership eligibility to keep the resulting choices legible.
Hitting one of these walls in your own codebase or your own machine? Start an assessment or talk to us.