标签：#stripe

Stripe and private equity firm Advent International have reportedly submitted a joint bid to acquire PayPal in a deal valued at approximately $53.4 billion. Reuters reports that the offer was submitted earlier this month and is backed by roughly $50 billion in committed bank financing. Under the proposal, Stripe and Advent would jointly own PayPal, […]

You built your WooCommerce store. You've got products, a checkout flow, and customers who want to pay in crypto. The question is: which payment gateway do you actually trust with your money? Most crypto payment plugins for WooCommerce work the same way: they collect your customer's payment, hold it in their own wallet, and send you a payout — minus fees, minus a wait, minus any guarantee they won't freeze your account if something looks "suspicious." That's not crypto. That's a bank with extra steps. This guide covers how to accept crypto payments on WooCommerce the non-custodial way — funds go directly from your customer's wallet to yours, on-chain, with no middleman holding anything. What "non-custodial" actually means for your store When a customer pays through a custodial processor, the money lands in the processor's wallet first. You're trusting them to forward it. If they freeze your account, dispute a transaction, or go under, your money is stuck. Non-custodial means the smart contract routes the payment directly to your wallet address. QBitFlow never holds your funds — not for a second. Every payment has an on-chain transaction hash you can verify on Etherscan, Solscan, or BaseScan. There's no one to call to "release" your money because no one ever had it. For a WooCommerce merchant, this matters for three reasons: No chargebacks. Crypto transactions are final. A customer can't call their bank and reverse a payment you already received. No holds. There's no processor deciding whether your business is "high-risk" this week. No conversion. You receive exactly what the customer paid — USDC stays USDC, ETH stays ETH. No auto-swap, no slippage, no surprise exchange rate. What you need before you start A WooCommerce store (WordPress + WooCommerce plugin installed) A crypto wallet — MetaMask, Coinbase Wallet, or any wallet that works with Reown/AppKit (browser extension or mobile QR scan) About 10 minutes That's it. No business registration. No KYC. No waiting for

I keep finding the same Stripe webhook bugs in SaaS launches Most early SaaS billing bugs are not in Stripe Checkout itself. They are in the glue around it: trusting the success redirect instead of the signed webhook parsing JSON before signature verification missing idempotency for retry events reflecting verifier errors from unauthenticated webhook routes updating subscription state without a replay/audit trail letting "Pro" access drift from the payment source of truth Over the last few days I have been shipping small public fixes around exactly this class of problem. Recent examples: Morphix: Cloudflare Worker Stripe webhook with signature verification, Supabase subscription sync, and event idempotency ledger https://github.com/yiyuanlee/morphix/pull/25 Open Mercato: hardened unauthenticated payment/shipping provider webhooks against raw verifier error reflection and missing rate limiting https://github.com/open-mercato/open-mercato/pull/2680 Covenant: webhook signatures hardened against replay and secret rotation gaps https://github.com/wienerlabs/covenant/pull/229 Volunteerflow: made a Stripe invoice.paid Founders Circle counter update transactional instead of partially committing user/counter state https://github.com/ppppowers/volunteerflow-project/pull/49 The pattern is boring in the best possible way: payment systems should be boring. The 48-hour version For a small SaaS that is about to turn on paid plans, I can take a bounded payment assurance sprint: inspect Checkout / webhook / subscription state flow verify signed webhook handling and raw-body behavior add idempotency around Stripe retry events ensure subscription status and entitlement state have one source of truth add a small regression test or smoke script leave a deploy/runbook note so the next failure is diagnosable Fixed scopes I am taking: $2,000 / 48 hours: one payment path hardened and documented $5,000 / 5 days: full launch pass across Checkout, webhook, subscription mirror, Pro gate, pricin

I build serious SaaS with my +20yr XP web & product. For my last SaaS I implemented Paddle as payment service because their baseline looked cool : Sell globally. Grow without the complexity. ⚠️ My apply was rejected after only 3min with 0 explanation... lol. Following a review of your account information, we are unable to complete the verification of your account. As a result, we cannot approve your application to use Paddle. Due to our internal security policies, we are unable to provide additional specifics or engage in further correspondence regarding this result. Paddle is not a serious service . I removed it from my tools list.

If you're building an AI app (image generation, transcription, an agent, anything that calls a model) you've probably realized a flat "$10/month" doesn't work. Every action costs you real money in GPU/API spend, so a single power user can torch your margins. The answer is usage credits : users buy a balance, each action spends some. Credits sound trivial. They are not. I've shipped about 10 small AI/SaaS apps, and the credit layer is where I got burned every single time. It took three patterns to fix it for good. Here they are, with copy-pasteable code for Next.js + Supabase + Stripe. Get these right and your billing won't oversell, double-charge, or strand a user's money. The three things everyone gets wrong Overdrawing. Two requests arrive at once, both read "balance = 1," both spend. Now the balance is negative and you gave away work for free. Double-granting. Stripe retries webhooks (it will ), and if you grant credits on every delivery, a $9 purchase becomes $18 of credits. Forgetting the refund. The AI job fails after you've already charged the credits. The user paid for nothing and emails you angry. Let's kill all three. Part 1. The atomic spend (overdraw becomes impossible) The mistake is doing the check in your app code: // DON'T: read-then-write has a race condition const { balance } = await getBalance ( userId ); if ( balance < cost ) throw new Error ( " insufficient " ); await setBalance ( userId , balance - cost ); // two concurrent requests both pass the check Do it in the database, in one statement, with the guard in the WHERE clause: -- balances: one row per user create table credit_balances ( user_id uuid primary key references auth . users ( id ) on delete cascade , balance integer not null default 0 check ( balance >= 0 ), updated_at timestamptz not null default now () ); -- append-only ledger = audit log + idempotency guard (see Part 2) create table credit_ledger ( id bigint generated always as identity primary key , user_id uuid not null referen

TL;DR Reconciliation is the part of a payments stack nobody architects for on day one and everyone pays for on day 200. The job: prove that every internal transaction matches the acquirer's settlement file, in the right currency, with the right fees, on the right value date — or surface the diff fast. The mechanics: normalize files → land into an events table → project to a read model → diff against the internal read model → buckets for ops to resolve. The boring details (file formats, fee parsing, FX rounding, value dates) are where 90% of the work lives. If you've ever opened a CSV from an acquirer at the end of the month, sorted by amount, and tried to "just match it in Excel" — yes, this post is for you. What "reconciled" actually means A transaction is reconciled when, for the same logical payment, three views agree: What you sent — your internal record of the charge/payout (your read model). What the acquirer says happened — their settlement file or API report. What the bank actually credited / debited — the bank statement. Disagreements are normal. Persistent disagreements are how you lose money slowly and never know. The shape of a settlement file Across the major acquirers, settlement files look broadly similar — and broadly different in the places that matter: Field Variants you'll see Transaction reference acquirer's transaction_id , sometimes plus a merchant_reference round-tripped from you Gross amount minor units / decimal; transaction currency vs settlement currency Fees inline per-row, or aggregated at the file footer, or in a separate fees file FX inline rate vs separate FX file; sometimes only the converted amount Value date when the bank actually moves money — often T+1/T+2 from event date Adjustments refunds, chargebacks, fee corrections, reserves — usually mixed in Encoding UTF-8 if you're lucky; CP1252 / fixed-width / SWIFT MT940 if you're not Granularity one row per transaction or daily aggregates per merchant or both There's no industry-clean