Why we picked the Stripe Refund API over manual ACH for consumer refunds

A protection product is only as fast as its slowest refund path. Choosing the right refund mechanism affects merchant trust, consumer perception, and the operational headcount required to keep things moving.

Two paths to send money back

The first option is the Stripe Refund API: refund against the original payment intent. Money goes back to the same card or bank account the consumer used at checkout. Settlement happens in the standard Stripe window. The second option is a fresh ACH transfer to a consumer-supplied bank account. More flexibility, more failure modes, more support cost.

Why we chose Refund API for the pilot

Three reasons. Reconciliation is automatic — refunds linked to the original charge appear in Stripe reports without manual matching. Consumer trust is higher because the refund lands in the same account they paid from. Operational complexity is lower because we don't collect bank details from consumers post-purchase.

When we'll revisit

If a merchant ships to regions where original-payment refunds are restricted, ACH or local-rail alternatives become necessary. We track this on the open-questions page; the architectural seams to add an alternate rail are intentional.

What this means for consumers

The refund timing commitment is on the public commitments page. The walk-back rule is documented — if the timing target slips, the commitment moves before the merchant relies on it.