Stripe delivery failure after payment leaves no charge-preserving retry path

[mh-yu]

Description

Stripe confirms the PaymentIntent before the application handler runs. If the handler fails or its response is lost, payment may succeed without resource delivery.

Replaying the credential returns the original PaymentIntent with an idempotent-replayed marker, which mppx rejects with 402. A fresh SPT uses a new idempotency key and may create another PaymentIntent, leaving no retry path that preserves the original charge.

Impact

A payer can have a succeeded Stripe payment without receiving the protected resource. The original credential cannot recover delivery, while retrying through a fresh challenge and SPT may require another payment. Stripe does not charge the same idempotency key twice; the risk arises when recovery moves to a new key.

Steps to reproduce

1. Use the mock Stripe client and replay test setup at src/stripe/server/Charge.test.ts:20-37 and src/stripe/server/Charge.test.ts:532-558.
2. Submit the credential. The PaymentIntent succeeds at src/stripe/server/Charge.ts:139-169; make the downstream handler at src/middlewares/hono.ts:68 fail or discard its response.
3. Replay the credential. The same idempotency key is used and Stripe reports the replay at src/stripe/server/Charge.ts:291-302.
4. Observe that mppx rejects it at src/stripe/server/Charge.ts:157-158 and returns 402 at src/server/Mppx.ts:1345-1363, as asserted at src/stripe/server/Charge.test.ts:568-574.
5. Follow the 402 with a fresh SPT through src/stripe/client/Charge.ts:50-94. Because the SPT is part of the idempotency key at src/stripe/server/Charge.ts:293, this permits a new PaymentIntent attempt.