Exactly right, and you've seen it firsthand. A payment facilitator (Stripe, Square, Toast) or a processor like Fiserv plugs into our API. When a refund is issued, it gets an immediate, tamper-proof settlement record on Kaspa that the merchant, PayFac, card issuer and customer can all verify. It doesn't make ACH or card settlement faster. What it does is give everyone a final, shared proof the refund was committed. That lets the PayFac or issuer credit the customer instantly, within their own risk limits, instead of making them wait 3–5 days. It eliminates refund-related disputes and mistaken chargebacks: "I never got my refund," duplicate refunds, and chargebacks filed after a refund already went out. Whoever fronts the instant credit is protected by the record, which is what makes it safe to do. It's a natural premium card perk too. Amex is both the network and the issuer, so it could roll out instant refunds to Platinum members on its own. Those customers feel the wait most and carry the lowest risk. The same play works for Sapphire Reserve or Venture X. There's no shared settlement record for refunds today. That's the gap we're closing.

Built on kaspa:native : Instant Refund Engine A card or ACH refund is approved in seconds but takes 3–5 business days to settle. That gap is where a big share of the ~$100B a year lost to returns fraud and abuse lives: duplicate refunds, refund-then-chargeback, and disputes that come down to whose logs you trust. Instant Refund is a refund settlement layer that uses Kaspa as the proof of finality. The existing rails keep moving the money. Each refund is anchored to the blockDAG as a signed transaction, so every party gets a final, verifiable record in seconds. No customer or card data goes on-chain. Under the hood: 1. FastAPI refund API with idempotent requests. 2. Postgres ledger and a row-locked settlement queue. 3. Workers send HMAC-authenticated intents that expire in 60 seconds. 4. A Rust sidecar holds the only key, checks it against the mainnet address at startup, then signs and submits to kaspad over gRPC. 5. Every refund maps to its Kaspa tx ID in a per-merchant compliance export. 6. The off-chain side is running. Wiring the Rust transaction path into the live sidecar is the current milestone. If you’re in payments, retail or the Kaspa ecosystem and this is useful to you, DM me. Design doc available. I pitched to a few FinTech CIOs but could not obtain seed funding. I also applied this product to @ycombinator but was denied acceptance. No active dev or sales.